Ordered replay oracle: pending window move rejects with later include-load error

オープン
#2,315 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

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

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
node.js, typescript

調査の方向性

Start with the replay.ordered-failed-replay property in packages/db/tests/query/load-subset-replay-refinement-oracle.test.ts and the recovery rules in packages/db/src/query/live/ARCHITECTURE.md. Run the supplied guarded replay from packages/db to confirm the error-identity failure, then trace how the model, driver, and comparison determine which failure decides the move. Done means the existing oracle passes the trace and nearby histories without weakening the assertion.

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

説明

bug
  • I've validated the bug against the latest version of DB packages

Describe the bug

The generated ordered-replay oracle finds a reproducible error-identity mismatch for a pending window move. After an include source's truncate replay fails, a later synchronous marker-load failure becomes the window move's rejection instead of the replay's earliest failure that still decides it.

Observed assertion:

replay error identity: move 1 rejected with "marker load threw", not its replay's earliest failure that still decides it

This is an assertion failure at the oracle comparison, not a timeout or setup failure. The same minimized history and assertion reproduce locally with PR #2309's production code and with the production changes reverted to its merge-base. The production/model cause has not been isolated.

To reproduce

Known failing source revision: a5c4986a14dc6c6a90ed9b194457edefba9a4a48 (the final head of merged PR #2309).

With dependencies installed, run from packages/db:

TANSTACK_DB_ORACLE_PROPERTY=replay.ordered-failed-replay TANSTACK_DB_ORACLE_SEED=963116110 TANSTACK_DB_ORACLE_PATH=318:2:1:6:5:7:6:6:6:6:9 node --import tsx tests/oracle-replay.ts   tests/query/load-subset-replay-refinement-oracle.test.ts   --maxWorkers=2 --coverage.enabled=false

The guarded replay records the requested property, seed and path, executes one failing history, and exits nonzero with the assertion above. The failing test is keeps the last publication through a failed replay (replay campaign).

The minimized generated input is:

[
  [
    { "type": "hold" },
    { "type": "truncateMarkers" },
    { "type": "window", "offset": 0, "limit": 1 },
    { "type": "settle", "ok": false, "newest": true },
    { "type": "markerThrows" },
    { "type": "move", "id": 4, "rank": 1 }
  ],
  {
    "direction": "desc",
    "offset": 0,
    "limit": 2,
    "ties": false,
    "peer": false,
    "joined": "none",
    "markerMode": "on-demand",
    "includes": true,
    "abortedMarkerLoads": "resolve",
    "historyDuringPreload": false
  }
]

These are inputs to the existing oracle driver, including its initial setup and final settlement. They are not a standalone public-API reproduction.

Expected behavior

A window operation waiting on a replay that fails must reject with that replay's own error: its earliest failure that still decides it. The architecture states this rule in Ordered requests, continuation, and recovery.

The final settlement checkpoint should pass the error-identity comparison without relaxing the oracle. Investigation should determine whether production loses the relevant failure or the oracle incorrectly attributes which replay/failure decides the move.

Evidence and scope

  • Failing CI job: the random campaign failed after 319 histories and ten shrink steps. The shard reported one failure and 10,080 passing tests.
  • Primary oracle and comparison: property replay.ordered-failed-replay.
  • Local guarded replay at a5c4986a14dc6c6a90ed9b194457edefba9a4a48: same minimized input, same assertion.
  • Baseline control: temporarily restored all eleven existing production files changed by #2309 to c351fc04d7f70dc59bf92ecbed310f899b9511cd, then ran the same guarded replay. It failed with the same input and assertion. The added unary-construction helper remained present but was unused by the restored operators. Every PR source file was restored afterward.
  • packages/db/src and this oracle file were unchanged between that merge-base and the PR head. This control establishes that #2309 did not introduce this failure. It was not a separate clean checkout of the entire baseline repository.
  • PR #2309 merged as 0531c50ad419a1b51ad3e27e3632e70be3c6bdb3 with this baseline failure explicitly accepted and recorded. The merged commit and current published package releases have not been independently replayed for this report.

Environment

  • CI: GitHub Actions, Ubuntu runner.
  • Local reproduction: macOS arm64, Node.js v24.19.0, pnpm 11.1.0.
  • Vitest 4.1.12, fast-check 3.23.2.

Repair validation

Preserve this trace as a replay through the shared model, driver and comparison. Use the existing primary oracle to check nearby histories with both rejected and synchronously throwing include loads, changing which failed demand remains relevant before the move settles. Establish the responsible production or model rule before changing expectations, then demonstrate RED/GREEN and a hostile mutant at the error-identity checkpoint.

主要言語
TypeScript
スター
4k
フォーク
277
平均マージ
1日 7時間
マージ済み PR(30日)
191

環境構築

はじめの一歩

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

TanStack/db のほかの issue

TanStack/db の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

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

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