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

Ordered loader: recover failed ordered requests with a bounded repair instead of a full-source read

Aperta
  • Qualcosa non va?
#2,165 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à
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
8/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
data-engineering

Direzione di ricerca

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.

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

Descrizione

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

  1. 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.
  2. Then change OrderedSourceLoader: fail, failRequest, finishOrderedPrefixRepair, abandonOrderedPrefixRepair, scheduleRepairRetry, and the retry gate in loadMore.
  3. 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".

Lingua principale
TypeScript
Stelle
4k
Fork
277
Merge medio
17h 33m
PR unite (30g)
227

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.