Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#2,165 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
8/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
data-engineering

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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".

主要言語
TypeScript
スター
4k
フォーク
277
平均マージ
17時間 40分
マージ済み PR（30日）
223

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

TanStack/db のほかの issue

TanStack/db の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。