Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#1,972 2 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
48/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
sqlite, typescript
Domínio
database

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
TypeScript
Estrelas
4k
Forks
277
Merge médio
18h 49min
PRs com merge (30d)
224

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de TanStack/db

Todas as issues de TanStack/db

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.