Load-subset replay oracle: failed marker load after marker truncate leaves the live query in a terminal error
Les mainteneurs répondent en général sous 1 jour
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 1-2 jours
- Accessibilité débutants
- 45/100
- Type d'issue
- Bug
- Clarté
- Plutôt claire
- Activité
- Active
- Stack technique
- typescript
Piste de recherche
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.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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.
- Langage dominant
- TypeScript
- Étoiles
- 4k
- Forks
- 277
- Merge moyen
- 17 h 40 min
- PR mergées (30 j)
- 223
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Propose un modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de TanStack/db
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
Les mainteneurs répondent en général sous 1 jour
-
Garbage collection cleans up a collection while one of its transactions is still persistingPeut-être pris @Nabil372 l’a pris il y a 1 jour. Ouverte
Difficulté 3/5 1-2 jours Accessibilité débutants 35/100
Les mainteneurs répondent en général sous 1 jour
-
persistedCollectionOptions without a schema can't be passed to createCollection (follow-up to #1452)Ouverte
Difficulté 3/5 1-2 jours Accessibilité débutants 68/100
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de TanStack/db
Issues similaires
-
Difficulté 1/5 Moins d'une heure Accessibilité débutants 70/100
microsoft/playwright#43640 ·
Les mainteneurs répondent en général sous 1 jour
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
grasshopper-protocol/grsshppr#172 ·
Les mainteneurs répondent en général sous 1 jour
-
bug help wanted
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
Tencent/teamai-cli#1397 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 70/100
DouyinFE/semi-design#3641 ·
Les mainteneurs répondent en général sous 3 jours
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 83/100
Les mainteneurs répondent en général sous 1 jour