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

On-demand joined window stays short after an optimistic delete of its visible row

Aberta
  • Algo errado?
#2,148 0 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
18/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
typescript
Domínio
databases

Direção de pesquisa

The ordered loader and its dataNeeded leading-run count are the starting points, along with how optimistic deletes hide loaded rows from the window. Reproduce with a live query using orderBy(rank).limit(1), a left-joined filter and an on-demand source, deleting the visible row with collection.delete(key) while the handler is pending. Done when the window refills with the next eligible row, and the pinned replay and fixed-point oracle dimension pass.

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

Descrição

Problem

Take a live query over an on-demand source, with an ordered window and a LEFT-joined (or anti-joined) filter. It can show a short window after an optimistic delete. The window stays short until the delete persists.

Example: orderBy(rank).limit(1), a joined filter, and an on-demand source. The application deletes the visible row with collection.delete(key). The handler's promise is still pending. The window shows [], but the next eligible row exists and the provider can serve it.

The same history passes when the filter is a source predicate, and when the source is eager. It fails with joined and anti-joined filters, with and without an index.

Evidence

  • The ordered-work oracle in #2132 has an optimistic-delete dimension. It is not committed yet, because the delete fails on main and on #2132. The #2132 worktree keeps the patch, and the fix PR will add it.
  • Before the oracle had a fixed-point guard, one random seed (1957256835) ran for more than ten minutes. This suggests that the loader can request the hidden row again and again.

Work

  • Find why the ordered loader does not refill a joined window when an optimistic delete hides a loaded row. A likely place is the leading-run count in dataNeeded, which can count the hidden row as a proven window row.
  • Add the oracle dimension and a pinned replay, with a fixed-point law for repeated requests.

This issue was written by Isaac.

Linguagem predominante
TypeScript
Estrelas
3.9k
Forks
272
Merge médio
1d 48min
PRs com merge (30d)
238

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.