Ordered loader: recover failed ordered requests with a bounded repair instead of a full-source read
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 8/100
- Tipo de issue
- Refactorización
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- typescript
- Área
- data-engineering
Línea de trabajo
The work centers on OrderedSourceLoader's fail, failRequest, finishOrderedPrefixRepair, abandonOrderedPrefixRepair, scheduleRepairRetry and the retry gate in loadMore. Before editing, read the ordered-source-loader, loader-state and pagination oracle tests, and the 'Ordered requests, continuation, and recovery' section of packages/db/src/query/live/ARCHITECTURE.md. Done means the bounded failure-recovery law is stated in those oracles and the pinned expectations, including the failing pagination-oracle tie-boundary and reject/abort lease cases, pass.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Problem
When an ordered request fails, the ordered loader recovers by reading the full source. That happens after a failed page, tie, or bounded-repair request, including a synchronous throw or a failed boundary read, and the automatic retries at 250 ms and 500 ms do the same. Full-source reads can be very expensive. Each plan that can continue from a provider prefix (!requiresFullSource) has a cheaper option: a bounded ordered-prefix repair from the start of the order. That repair sets its boundary from its own settled requests, so partial writes from the failed request cannot mislead it.
Rule (maintainer decision): avoid full-source reads whenever a bounded read is available.
PR #2154 applies this rule to an ordering invalidation that overlaps an in-flight page or tie request. It leaves failure recovery unchanged. These paths still read the full source:
- recovery after a failed or canceled request;
- an ordering invalidation that arrives before any request has settled.
What a first attempt showed
A prototype replaced requireFullSourceRepair() with a bounded repair on failure. It also retried the bounded repair in the automatic retries, and let a newer ordering invalidation retry once. Across five test files, 48 pinned expectations then failed. Some of them were real regressions:
pagination-oracle.property.test.ts, "recovers a failed tie boundary …": the window was[1, 4], expected[1, 2].ordered-source-loader-oracle.test.ts, "keeps the 'boundary' acquisition lifecycle exact for reject/abort": after the tie request failed, the original page acquisition was not released.pagination-oracle.property.test.ts, the pending-history campaigns and their captured-history controls: logical settlement did not match the model.
The failure path re-enters the bounded chain in states it was not built for, for example a failed request that overlaps a repair (the abandonOrderedPrefixRepair path).
Work
- In the ordered-source-loader, loader-state and pagination oracles, state the bounded failure-recovery law first:
- recovery shapes;
- the lease release of failed and superseded acquisitions;
- the retry budget;
- retry after a newer invalidation.
- Then change
OrderedSourceLoader:fail,failRequest,finishOrderedPrefixRepair,abandonOrderedPrefixRepair,scheduleRepairRetry, and the retry gate inloadMore. - Update "Ordered requests, continuation, and recovery" in
packages/db/src/query/live/ARCHITECTURE.md.
Related: #2136, #2154. The coverage map backlog entry is "Bounded recovery after a failed ordered request".
- Lenguaje dominante
- TypeScript
- Estrellas
- 4k
- Forks
- 277
- Merge medio
- 17 h 40 min
- PR fusionados (30 d)
- 223
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de TanStack/db
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
Garbage collection cleans up a collection while one of its transactions is still persistingPosiblemente ocupada @Nabil372 la tomó hace 1 día. Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
Los mantenedores suelen responder en 1 día
-
persistedCollectionOptions without a schema can't be passed to createCollection (follow-up to #1452)Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
Todos los issues de TanStack/db
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
Merit-Systems/x402scan#1312 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Native Web
Dificultad 1/5 Menos de una hora Aptitud para principiantes 80/100
digitalfabrik/integreat-app#4517 ·
Los mantenedores suelen responder en 2 días
-
TLS guide repeats certs/ in the certificate directoryPosiblemente ocupada @maheshrijal la tomó hoy. Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 92/100
prometheus/docs#3156 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 83/100
medusajs/dtc-starter#90 ·
Los mantenedores suelen responder en 1 día