Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#2,148 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
18/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript
Área
databases

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
3.9k
Forks
272
Merge medio
1 d 48 min
PR fusionados (30 d)
238

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de TanStack/db

Todos los issues de TanStack/db

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.