Persisted collections: the sync wrapper's loadSubset is always async, so a live query over a loaded on-demand collection is never synchronously ready
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 72/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- react, typescript
- Ambito
- database
Direzione di ricerca
Start in packages/db-sqlite-persistence-core/src/persisted.ts at createWrappedSyncConfig and compare its loadSubset behavior with the LoadSubsetFn contract in packages/db/src/types.ts and CollectionSyncManager.loadSubset in packages/db/src/collection/sync.ts. Reproduce with the node and browser examples, then add focused coverage near packages/db-sqlite-persistence-core/tests/persisted.test.ts; done means an already-loaded persisted subset returns synchronously and the Suspense case reaches ready.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
- I've validated the bug against the latest version of DB packages (
@tanstack/[email protected],@tanstack/[email protected],@tanstack/[email protected])
Describe the bug
createWrappedSyncConfig in db-sqlite-persistence-core returns its loadSubset as an async function, so it is always a Promise — even when everything it awaits is already settled and the wrapped sync answered with a synchronous true.
That matters because LoadSubsetFn is declared as a sometimes-synchronous contract in packages/db/src/types.ts:
export type LoadSubsetFn = (options: LoadSubsetOptions) => true | Promise<void>
and CollectionSyncManager.loadSubset branches on it (packages/db/src/collection/sync.ts:853):
if (result instanceof Promise) { this.trackLoadPromise(result); ... }
return true
An async implementation can never reach the true branch. So for any persisted collection, a live query over an already-loaded subset is never synchronously ready.
Under useLiveSuspenseQuery that is fatal rather than merely slow: a component that suspends before it mounts loses its refs, so each retry constructs a fresh live query, which is loading, which throws a fresh promise, which resolves, which retries. The boundary never releases.
To Reproduce
Full runnable repro (node + real-browser): https://gist.github.com/MAST1999/62526dceb542323d009d036e3bb8ed7e
npm install
npm run node # the cause — no React, no browser
npm run browser # the symptom — real Chromium via @vitest/browser
There is no SQLite in the repro. It uses an in-memory PersistenceAdapter of the same shape as this repo's own createRecordingAdapter in packages/db-sqlite-persistence-core/tests/persisted.test.ts, because the defect is in the sync wrapper that persistedCollectionOptions puts in front of any adapter. The only difference between the two cases is whether the options went through persistedCollectionOptions.
The mock sync returns a bare true from loadSubset for a subset it has already loaded, which is exactly what the declared contract is for:
loadSubset: (options) => {
const key = JSON.stringify(options.where ?? null)
if (loaded.has(key)) return true // already here — nothing to await
loaded.add(key)
begin(); for (const row of ROWS) write({ type: `insert`, value: row }); commit()
return true
}
node-repro.mjs:
no persistence : ready (2 rows loaded)
persisted : loading (2 rows loaded)
suspense.test.jsx, in Chromium:
✓ an unpersisted on-demand collection settles under Suspense 54ms
× the same collection with persistence never leaves its fallback
→ the boundary never released; the component re-suspended 13778 times
Expected behavior
A persisted on-demand collection should honour the same true | Promise<void> contract as an unpersisted one: when the wrapped sync answers true and there is nothing left to await, the wrapper should return true too, and the live query should be ready at construction.
Cause
packages/db-sqlite-persistence-core/src/persisted.ts, createWrappedSyncConfig (line 2654 on main @ dffb17f):
loadSubset: async (options: LoadSubsetOptions) => {
const acquisition = { forwarded: false }
acquisitions.set(options, acquisition)
await fullStartPromise
const resolvedSourceResult = await sourceResultPromise
...
return runtime.loadSubset(options, (loadOptions) => { ... })
}
Note also that runtime.loadSubset (line 1043) re-runs hydrateSubsetUnsafe against the store on every call, including a repeat call for a subset already in activeSubsets — so the redundant work is real, not just the lost true.
async syntax structurally cannot express T | Promise<T> (microsoft/TypeScript#33595), so conforming to LoadSubsetFn requires hand-writing the branch.
Prior art in this repo
@tanstack/electric-db-collection writes its raw fetcher as async too, but does not hand it back directly — it wraps it (packages/electric-db-collection/src/electric.ts:860):
return new DeduplicatedLoadSubset({ loadSubset })
and DeduplicatedLoadSubset.loadSubset returns the literal true for an already-completed demand key. grep -rn "DeduplicatedLoadSubset" packages/db-sqlite-persistence-core/src/ returns nothing — the persistence package skips that layer entirely.
Additional context
This is distinct from #1855 (orderBy + limit chaining subset requests), though the two share a symptom. This one needs no orderBy and no limit — just persistence.
Happy to open a PR.
- Lingua principale
- TypeScript
- Stelle
- 3.9k
- Fork
- 272
- Merge medio
- 1g 1h
- PR unite (30g)
- 212
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di TanStack/db
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
electric-db-collection: on-demand + persistence fails after relaunch with "Snapshot requests are not supported in full mode"Forse già presa @KyleAMathews l’ha presa 3 giorni fa. Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 68/100
TanStack/db#2056 · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
TanStack/db#1972 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 45/100
I maintainer di solito rispondono entro 1 giorno
Issue simili
-
area: desktop area: website priority: P2 type: feature
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
appandflow/stim#3411 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
needs triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
rjsf-team/react-jsonschema-form#5485 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 65/100
lingdojo/kana-dojo#32090 · 1 commento · 5 reazioni ·
I maintainer di solito rispondono entro 1 giorno
-
Friction: Org home and org switcher copy still say repositories and connected agents live in the personal accountForse già presa Una pull request collegata a questa issue è aperta o già unita. Apertafriction
Difficoltà 2/5 1-3 ore Idoneità per principianti 80/100
kentcdodds/kody#3265 ·
I maintainer di solito rispondono entro 1 giorno