Restore Query DB receiving histories omitted during PR integration
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 8/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Attiva
- Stack tecnologico
- sql, sqlite, typescript
- Ambito
- testing-qa
Direzione di ricerca
Start with docs/contributing/oracle-coverage.md near the Query DB ownership section to see which histories are listed as missing, then read load-subset-lifecycle-oracle.test.ts and ownership-lifecycle.oracle.test.ts. Done means new public-history tests with wrong-design controls, scratch failures classified as invalid fixture, production defect or open contract question, and the coverage map updated.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Coverage gap
The #2134 branch once had public receiving histories for Query Core observer handoff, paused and reentrant replacement fetches, refetch cancellation, and nested fetch order across direct writes. Some did not survive its integration with #2158 at executable merge 2089e0630.
The current merged tree has strong named and generated lifecycle coverage. It does not replay every earlier receiving path. docs/contributing/oracle-coverage.md lists the missing paths near the Query DB ownership section. A scratch merge of the older tests with the published-Core adapter reported 68 failures among 841 tests. Some fixtures assumed an eager signal data descriptor or same-stack physical abort. The current adapter uses a lazy getter and Query Core's release turn. Those fixture failures are not evidence of product bugs; the remaining public-law failures have not been classified.
Oracle owners and acceptance
- Extend
load-subset-lifecycle-oracle.test.tswith outside-observer handoff, cleanup, paused-fetch, and reentrant replacement histories. Compare the physical signal, Query cache, caller settlement, and full public rows after the correct release and application cuts. - Extend
ownership-lifecycle.oracle.test.tswith nested fetch-start order across accepted direct writes. Add explicit refetch and snapshot histories that compare each caller's result with its own applied replacement. - Derive expected outcomes from the Collection sync-adapter contract and Query Collection guide. Do not copy Query DB's current fetch classifier into the reference model.
- Calibrate at least one wrong-design control at each new public comparison. Classify old scratch failures as invalid fixture, production defect, or unresolved contract question before changing assertions.
- Update the coverage map with the exercised histories and remaining limits. File confirmed product defects separately. #2176 already tracks non-source Query result provenance.
This is follow-up oracle work. It does not change the bounded identity, primitive SQLite upgrade, or #2158 acquisition claims already reviewed in those PRs.
- Lingua principale
- TypeScript
- Stelle
- 3.9k
- Fork
- 272
- Merge medio
- 1g 21m
- PR unite (30g)
- 241
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 25/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 5/100
TanStack/db#2186 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
query-db: a Query refetch that joins a loader's refetch acquisition does not report shifted pagesAperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 8/100
TanStack/db#2185 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
A live query's preload on an on-demand collection waits for any persisting optimistic transactionAperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 12/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 18/100
I maintainer di solito rispondono entro 1 giorno
Issue simili
-
area:ui effort:S enhancement priority:P2
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 74/100
QuantumNous/new-api#7839 ·
I maintainer di solito rispondono entro 1 giorno
-
good first issue maintenance
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
dark-princezz/stellar-hooks#1010 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
interledger/rhyza#352 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
I maintainer di solito rispondono entro 1 giorno