@tanstack/db@0.9.2 · @tanstack/electric-db-collection@0.4.10 · @electric-sql/client@1.5.28
(latest at time of writing)
docker compose up -d # Postgres + Electric, the pair TanStack DB's own e2e suite expects
npm install
node repro.mjsNothing here fakes the wire — it runs against a real Electric.
Ten live queries, each with a distinct where predicate, each fully awaited
before the next is created. No concurrency, nothing superseded, nothing racing.
The underlying table never changes.
distinct subsets requested : 10
non-live shape requests : 20
snapshots (POST) : 0
chunk refetches (GET) : 20
distinct offsets requested : 4
requests per subset : 2.00
subset requests : 10
first six non-live requests:
GET ?log=changes_only&offset=now&subset__params=...&subset__where="n" >= $1&table=items
GET ?handle=...&log=changes_only&offset=0_inf&table=items
GET ?handle=...&log=changes_only&offset=0_inf&subset__params=...&subset__where=...
GET ?handle=...&log=changes_only&offset=0_inf&table=items
GET ?handle=...&log=changes_only&offset=0_inf&subset__params=...&subset__where=...
GET ?handle=...&log=changes_only&offset=0_inf&table=items
The requests alternate. Ten of them are the subset requests themselves, which
are expected. The other ten carry no subset__ parameters at all and repeat
the same offset=0_inf — they are the forceDisconnectAndRefresh() that
precedes each requestSnapshot.
Ten identical same-offset requests is exactly the pattern
@electric-sql/client treats as a broken cache, so its guard fires:
[Electric] Detected fast retry loop (5 requests in 500ms at the same offset).
Clearing client-side caches and resetting stream to recover. If this persists,
check that your proxy includes all query parameters (especially 'handle' and
'offset') in its cache key, and that required Electric headers are forwarded to
the client.
The proxy is fine. The duplicate requests come from the adapter.
It demonstrates the request amplification and the spurious guard trip. It does not demonstrate a permanently dead stream — the client recovers here. Higher subset churn is where that would be worth investigating, and this repro does not establish it.