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

Load-subset replay oracle: failed marker load after marker truncate leaves the live query in a terminal error

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

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

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

評価

難易度
4/5
見積もり時間
1〜2日
初心者へのやさしさ
45/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
database, testing

調査の方向性

Start with packages/db/tests/query/load-subset-replay-refinement-oracle.test.ts, especially the named random-campaign test and fatalLoadFailed() near line 1875. Reproduce with the supplied seed and inspect how the oracle models a held load that fails after marker truncation; compare that with the recovery behavior described in ARCHITECTURE.md. Done means deciding whether the model or production behavior is wrong and updating the relevant code or oracle so the seeded case and fixed campaign agree.

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

説明

Summary

The random campaign of the load-subset replay refinement oracle fails on main (427a7c31e). A live query ends in the error status after a failed marker load. The oracle's model says no fatal load failed in this history, so it expects the window to recover.

  • Test: packages/db/tests/query/load-subset-replay-refinement-oracle.test.ts › "Ordered windows across truncate replays › keeps the ordered window under load and release faults (random campaign)"
  • Assertion: convergence: terminal error: expected false to be true (line 1875: expect(fatalLoadFailed(), ...).toBe(true))

Reproduce

cd packages/db
TANSTACK_DB_ORACLE_SEED=1930131799 npx vitest run \
  tests/query/load-subset-replay-refinement-oracle.test.ts \
  -t "load and release faults \(random"

fast-check output:

{ seed: 1930131799, path: "33:3:1:4:0:2:3:2:2", endOnFailure: true }
Counterexample: [[{"type":"hold"},{"type":"truncateMarkers"},{"type":"settle","ok":false}],{"direction":"asc","offset":0,"limit":1,"ties":false,"peer":false,"joined":"none","markerMode":"on-demand","includes":true}]
Shrunk 8 time(s)

The shrunk history:

  1. hold the loads;
  2. truncate the marker source;
  3. settle the held loads with a failure.

The scenario is an ascending window (offset 0, limit 1) with on-demand markers and includes, no ties, no peer and no join.

What the oracle checks

After the faults, the recovery step truncates every source, settles, and moves the window again explicitly. A failed replay keeps the last complete publication until a later authoritative replay, and a failed window operation stays private until a later explicit move revalidates it (see ARCHITECTURE.md). After that, the live query must either show the expected window, or be in error only if fatalLoadFailed() (demandFailed || failedWhileLoading) holds. In this history the query is in error, but fatalLoadFailed() is false.

Undecided

Two explanations fit this result, and I haven't decided between them:

  • Production defect: a marker load that fails while held across a marker truncate becomes a terminal query error, though the documented recovery should clear it.
  • Model gap: this failure really is fatal, and fatalLoadFailed() misses the case where a marker load fails after a marker truncate.

The fixed campaign passes. I found this while working on #2220 (branch issue-2220-sync-metadata-held-reads), but it reproduces on a clean main checkout, and that branch doesn't touch this oracle or its production path.

主要言語
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 を短くまとめたダイジェスト。