Ordered replay oracle: pending window move rejects with later include-load error
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 35/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- node.js, typescript
- 領域
- databases, testing-qa
調査の方向性
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 の本文から書いたものです。
説明
- 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/srcand 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
0531c50ad419a1b51ad3e27e3632e70be3c6bdb3with 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, pnpm11.1.0. - Vitest
4.1.12, fast-check3.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
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
TanStack/db のほかの issue
-
難易度 1/5 1〜3時間 初心者へのやさしさ 88/100
メンテナーはふだん 1 日以内に返信
-
OfflineExecutor.dispose() never settles pendingTransactionPromises対応中かも @Claire-ovo が 5 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
Two @tanstack/db tests time out under CPU load because a cold module import counts against the 5 s default timeout対応中かも @jp-knj が 3 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
Disabled useLiveQuery fails SSR hydration with error 253対応中かも @Jaime02 が今日担当しました。 オープン
難易度 4/5 3〜5日 初心者へのやさしさ 42/100
メンテナーはふだん 1 日以内に返信
似ている issue
-
bug low priority
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
enhancement good first issue
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
laaielichter/Godotwright#81 ·
メンテナーはふだん 1 日以内に返信
-
gebied: infra
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
VincentSmedinga/sc-heerenveen-fansite#538 ·
メンテナーはふだん 1 日以内に返信
-
CI grants a token it does not need, never cancels superseded runs, and cannot fail on lint warningsオープンgood first issue help wanted type:infrastructure type:security
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
Open-Glassbeetle/glassbeetle#247 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信