query-db refetch oracle: a window row is missing from the source Collection after a held delete is released
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 48/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- typescript
Direzione di ricerca
Start with packages/query-db-collection/tests/refetch-ordered-prefix-oracle.test.ts and run the supplied seed and path using the reproduction command. Trace the held delete, refetch, and release through the query-db code and compare the source Collection with the ordered window after release. Done means the reproduced history satisfies the coverage law, with the relevant tests passing.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Summary
The query-db refetch oracle fails on main at bd10e564e for one random seed. The history has a held delete, two upserts, a refetch, and the release of the held delete. After it, a row sorts inside the live window, but the source Collection does not have it.
Reproduction
pnpm install
pnpm --filter @tanstack/db-ivm build
pnpm --filter @tanstack/db build
pnpm --filter @tanstack/db-sqlite-persistence-core build
cd packages/query-db-collection
TANSTACK_DB_ORACLE_SEED=-116668131 \
TANSTACK_DB_ORACLE_PATH="71:3:0:2:1:1:2:3:0:5:5:4:0:0:0:0:3:1:2:4:4:7" \
TANSTACK_DB_ORACLE_PROPERTY=query-db.refetch-ordered-prefix \
npx vitest run tests/refetch-ordered-prefix-oracle.test.ts
The random campaign of query-db.refetch-ordered-prefix found the seed. In my runs, approximately 1 of 3 random campaigns failed.
Shrunk counterexample
{
"scenario": { "encoding": "cursor", "functionKey": false, "terms": 1, "orderKey": "rank", "limit": 1, "offset": 0 },
"initial": [
{ "id": 0, "rank": 0, "marked": false },
{ "id": 1, "rank": 0, "marked": false }
],
"history": [
{ "type": "hold", "kind": "delete", "id": 1 },
{ "type": "upsert", "id": 2, "rank": 0 },
{ "type": "upsert", "id": 1, "rank": 1 },
{ "type": "refetch" },
{ "type": "release" }
]
}
Failure
coverage after release at step 4: rows [{"id":2,"rank":2,"label":"a2"}] sort at or before the window's end but are [null] in the source Collection
The coverage law applies after the release of the held write. Every row that sorts at or before the end of the served window must then be in the source Collection. Here, row 2 sorts inside the window, but the source Collection does not contain it.
Scope
- The failure also occurs with the live-query sources of #2194 and of its merge base, so it does not come from #2194.
- I did not find the cause. The shrunk history has a held delete of row 1 while row 2 is inserted, row 1 moves, and a refetch runs. That points at the refetch and the release of the held write, possibly near #2206.
This issue was written by Isaac.
- Lingua principale
- TypeScript
- Stelle
- 3.9k
- Fork
- 277
- Merge medio
- 17h 54m
- PR unite (30g)
- 226
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à 3/5 1-2 giorni Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
I maintainer di solito rispondono entro 1 giorno
-
SQLite persistence: a sync transaction whose durable write fails still changes the public CollectionAperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
-
sqlite-persistence: leader term write on every page load delays reading rowsForse già presa @KyleAMathews l’ha presa oggi. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 50/100
I maintainer di solito rispondono entro 1 giorno
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
kunchenguid/gh-axi#220 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 79/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
prerender: wait for env-runner worker readiness before crawlingForse già presa @sarankumar1325 l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno