Load-subset replay oracle: failed marker load after marker truncate leaves the live query in a terminal error
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 45/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- typescript
Direzione di ricerca
Start with packages/db/tests/query/load-subset-replay-refinement-oracle.test.ts, especially the named random-campaign test and fatalLoadFailed() near line 1875. Reproduce with the supplied seed and inspect how the oracle models a held load that fails after marker truncation; compare that with the recovery behavior described in ARCHITECTURE.md. Done means deciding whether the model or production behavior is wrong and updating the relevant code or oracle so the seeded case and fixed campaign agree.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Summary
The random campaign of the load-subset replay refinement oracle fails on main (427a7c31e). A live query ends in the error status after a failed marker load. The oracle's model says no fatal load failed in this history, so it expects the window to recover.
- Test:
packages/db/tests/query/load-subset-replay-refinement-oracle.test.ts› "Ordered windows across truncate replays › keeps the ordered window under load and release faults (random campaign)" - Assertion:
convergence: terminal error: expected false to be true(line 1875:expect(fatalLoadFailed(), ...).toBe(true))
Reproduce
cd packages/db
TANSTACK_DB_ORACLE_SEED=1930131799 npx vitest run \
tests/query/load-subset-replay-refinement-oracle.test.ts \
-t "load and release faults \(random"
fast-check output:
{ seed: 1930131799, path: "33:3:1:4:0:2:3:2:2", endOnFailure: true }
Counterexample: [[{"type":"hold"},{"type":"truncateMarkers"},{"type":"settle","ok":false}],{"direction":"asc","offset":0,"limit":1,"ties":false,"peer":false,"joined":"none","markerMode":"on-demand","includes":true}]
Shrunk 8 time(s)
The shrunk history:
- hold the loads;
- truncate the marker source;
- settle the held loads with a failure.
The scenario is an ascending window (offset 0, limit 1) with on-demand markers and includes, no ties, no peer and no join.
What the oracle checks
After the faults, the recovery step truncates every source, settles, and moves the window again explicitly. A failed replay keeps the last complete publication until a later authoritative replay, and a failed window operation stays private until a later explicit move revalidates it (see ARCHITECTURE.md). After that, the live query must either show the expected window, or be in error only if fatalLoadFailed() (demandFailed || failedWhileLoading) holds. In this history the query is in error, but fatalLoadFailed() is false.
Undecided
Two explanations fit this result, and I haven't decided between them:
- Production defect: a marker load that fails while held across a marker truncate becomes a terminal query error, though the documented recovery should clear it.
- Model gap: this failure really is fatal, and
fatalLoadFailed()misses the case where a marker load fails after a marker truncate.
The fixed campaign passes. I found this while working on #2220 (branch issue-2220-sync-metadata-held-reads), but it reproduces on a clean main checkout, and that branch doesn't touch this oracle or its production path.
- Lingua principale
- TypeScript
- Stelle
- 4k
- Fork
- 277
- Merge medio
- 17h 33m
- PR unite (30g)
- 227
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à 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
Electric: scoped move-in snapshots can prematurely resolve awaitTxId and remove optimistic rowsAperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 38/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 1-2 giorni Idoneità per principianti 48/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 1-2 giorni Idoneità per principianti 48/100
I maintainer di solito rispondono entro 1 giorno
Issue simili
-
[Bug]: Device screenshot fails with 500 on iPhone Duo (Xcode 27.2): serve-sim calls simctl without --displayForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
pingdotgg/t3code#24900 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
inu-appcenter/UNIDorm-web#411 ·
I maintainer di solito rispondono entro 1 giorno
-
🐛 bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
ranxianglei/billion-context#4720 ·
I maintainer di solito rispondono entro 1 giorno
-
area:arcade game p3-medium ready-for-agent type:bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
fderuiter/deruiter.dev#2840 ·
I maintainer di solito rispondono entro 1 giorno