Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Automatic Query Collection refetch still has no observable result-application settlement

Aperta
  • Qualcosa non va?
#1,972 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

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
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
sqlite, typescript
Ambito
database

Direzione di ricerca

Start in the Query Collection implementation where pendingResultApplications is tracked, then inspect collection.utils and the existing utils.refetch barrier. Use the linked downstream patch and regression test as behavioral references, including automatic invalidation/revalidation and unchanged results. Done means a public observable settlement signal covers every automatic query result without changing the explicit refetch barrier.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Versions

@tanstack/[email protected], @tanstack/[email protected], @tanstack/[email protected], @tanstack/[email protected], @tanstack/[email protected].

Problem

#1828 was closed after utils.refetch() became an awaitable result-application barrier. That fixes an explicit refetch. An automatic Query Collection refetch (Query invalidation/revalidation) still has no public way for a reactive consumer to tell whether its result has finished applying to collection rows.

With an existing persisted row, hold the SQLite commit that applies a newer fetched result. The Query cache already reports a successful, idle fetch with a newer dataUpdatedAt, while collection.get(key) still returns the old row. The pending application is tracked internally by pendingResultApplications, but collection.utils does not expose it. When the result is identical to existing rows, application completion emits no collection change event, so observing collection changes cannot close the gap either.

Our status hook needs this distinction before it treats collection rows as authoritative for a user decision. We currently patch 1.3.1 to expose isApplyingResult and subscribeResultApplications (start, invalidation, and settlement, including empty diffs): downstream patch and regression test.

Expected

Either a public application-phase state with a subscription, or an observable successful-application event/revision that advances for every automatic query result, including an unchanged result. The explicit utils.refetch() barrier can remain as it is; the missing case is work initiated by the Query Collection itself.

Lingua principale
TypeScript
Stelle
3.9k
Fork
268
Merge medio
1g 3h
PR unite (30g)
147

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di TanStack/db

Tutte le issue di TanStack/db

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.