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

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

Aperta
  • Qualcosa non va?
#2,148 0 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
18/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
databases

Direzione di ricerca

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.

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

Descrizione

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.

Lingua principale
TypeScript
Stelle
3.9k
Fork
272
Merge medio
1g 48m
PR unite (30g)
238

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.