Persisted Query Collection can enter error state when refetch supersedes a pending SQLite application
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 48/100
- Issue-Typ
- Bug
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- sqlite, typescript
- Bereich
- databases, testing-qa
Rechercherichtung
Start by tracing enqueueResultApplication, invalidatePendingResultApplication, and trackResultApplication through the persisted Query Collection and sync transaction code. Reproduce the interleaving with the described node:sqlite integration test, focusing on the result of commit(signal) and pending SQLite application. Done means the second refetch exposes value 3 without an application error or a stale value 1.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Versions
@tanstack/db0.11.1@tanstack/query-db-collection1.3.2@tanstack/expo-db-sqlite-persistence0.2.26@tanstack/react-db0.5.1
Problem
A second refetch of a persisted Query Collection can leave an active collection in error when the previous query result has already committed a sync transaction but SQLite has not applied it yet. This happens during ordinary use, without cleanup or a session change.
The adapter logs:
[QueryCollection] Error applying query overlap: AbortError: Sync transaction was aborted before application
[Live Query Error] Source collection 'overlap' entered error state
The collection can retain the old row after both refetches settle.
Deterministic reproduction
- Create a persisted Query Collection with one row
{ id: 'row', value: 1 }, a QueryClient, and an Expo-SQLite-compatible database. Preload it. - Decorate the database
runAsyncto await a deferred promise when aholdWritesflag is set. This delays SQLite application without delayingqueryFn. - Set
holdWrites = true, change the server row to{ id: 'row', value: 2 }, and callcollection.utils.refetch(). - Wait until the query fetch is idle and its result has started applying to SQLite (the decorated
runAsynchas entered the wait). - Change the server row to
{ id: 'row', value: 3 }and callcollection.utils.refetch()again. - Release the SQLite write; await both refetches.
Expected: value 3 is visible; no collection application error.
Actual: an AbortError is logged by trackResultApplication, and the visible row can remain value 1. The second query function did run, so this is not a fetch deduplication issue.
This also occurs when a mutation handler publishes an authoritative server row with writeUpsert while a query refresh is in flight, as in our XP award collection.
Likely cause
enqueueResultApplication calls invalidatePendingResultApplication for the previous result. That unconditionally aborts its controller. When its sync transaction has already been committed and is waiting for SQLite, aborting it removes it from the core pending queue. The newer transaction for the same row can depend on that queued transaction and gets invalidated too (SyncTransactionAbortedError).
I reproduced this in a real node:sqlite integration test. Keeping committed sync transactions alive until their SQLite application finishes, while still aborting pre-commit work, makes the test pass. A guard around cancellation after commit(signal) returns a pending application receipt is one possible fix. This is a suggested direction, not a claim that it covers all interleavings.
- Vorherrschende Sprache
- TypeScript
- Sterne
- 3.9k
- Forks
- 268
- Ø Merge
- 1 T. 2 Std.
- Gemergte PRs (30 T.)
- 206
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus TanStack/db
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 45/100
Maintainer antworten meist innerhalb von 1 Tag
-
Reusable queries: standalone descriptor resolution and nested alias composition limitsEvtl. vergeben @KyleAMathews hat das vor 1 Tag übernommen. Offen
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 25/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 72/100
Maintainer antworten meist innerhalb von 1 Tag
-
electric-db-collection: on-demand + persistence fails after relaunch with "Snapshot requests are not supported in full mode"Evtl. vergeben @KyleAMathews hat das vor 1 Tag übernommen. Offen
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 68/100
TanStack/db#2056 · 1 Reaktion ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 48/100
TanStack/db#1972 · 2 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
Ähnliche Issues
-
First unknown-user login after boot is one scrypt run slower than a real user's wrong passwordOffenarea: backend bug priority: low
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
snapotter-hq/SnapOtter#2254 ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug ticket
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
cratestack/cratestack#1154 ·
Maintainer antworten meist innerhalb von 1 Tag
-
server 消息处理器 cmd 分支补显式错误回报——竞态非法命令现走未处理拒绝Evtl. vergeben @openaddr hat das heute übernommen. Offenready-for-agent refactor wayfinder:task
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
openaddr/dafung-web#428 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Flaky: mongodb-memory-server 'Port already in use' when another process starts a mongod concurrentlyOffenarea:testing bug effort:S priority:P2
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
Maintainer antworten meist innerhalb von 1 Tag
-
lens:agent lens:process process
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
thebristolsound/birdbrain#1772 ·
Maintainer antworten meist innerhalb von 1 Tag