Ordered live query publishes new rows during a failed marker replay
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
- issue の種類
- バグ
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
- 技術スタック
- typescript
- 領域
- backend, testing-qa
調査の方向性
Start with packages/db/tests/query/load-subset-replay-refinement-oracle.test.ts and replay the recorded seed and path using the provided Vitest command. Compare the production behavior with the shared model/driver comparison and the deferred trace cited in the issue, checking whether the barrier remains held or fails at the recorded cut. Done means identifying whether the counterexample exposes a production defect or a model/observation-cut defect, preserving both traces, and adding the requested neighboring cases before any production repair.
索引モデルが issue の本文から書いたものです。
説明
A generated replay-retention history failed on main at 82c5f999b32c9db827dd74e3f172604dfda28013 while preparing the first RC. The query published row 3 while its retained complete result was still empty.
CI evidence
- Failed Release job
- Owner:
load-subset-replay-refinement-oracle.test.ts - Property:
replay.ordered-failed-replay, random campaign - Seed:
-2135028650 - Path:
249:0:1:1:1:1:1:5:6 - Checkpoint:
retained publication once loading is quiet,checkRetentionline 1444 - Result: 9,771 tests passed, one assertion failed, no type errors. This was not a timeout or a missing-reach failure.
- Host: GitHub Actions Ubuntu, Node 24.8.0, Vitest 4.1.12, fast-check 3.23.2.
expected [ { id: 3, rank: 30, … } ] to deeply equal []
Shrunk history
[
{ "type": "hold" },
{ "type": "truncateMarkers" },
{ "type": "settle", "ok": true, "keepHolding": true, "newest": false },
{ "type": "settle", "ok": true, "keepHolding": true, "newest": false },
{ "type": "settle", "ok": false, "newest": true, "keepHolding": true },
{ "type": "mark", "id": 3, "on": false }
]
{
"direction": "asc",
"offset": 1,
"limit": 1,
"ties": false,
"peer": false,
"joined": "none",
"markerMode": "on-demand",
"includes": true,
"abortedMarkerLoads": "resolve",
"historyDuringPreload": false
}
Replay from packages/db on the recorded commit with its dependencies installed:
TANSTACK_DB_ORACLE_PROPERTY=replay.ordered-failed-replay \
TANSTACK_DB_ORACLE_SEED=-2135028650 \
TANSTACK_DB_ORACLE_PATH=249:0:1:1:1:1:1:5:6 \
pnpm exec vitest run \
--coverage.enabled=false --typecheck.enabled=false \
tests/query/load-subset-replay-refinement-oracle.test.ts \
-t 'keeps the last publication through a failed replay'
The seed, path, history and mismatch above are from the executed CI run. This exact trace has not been independently replayed on the older main baseline, so it does not yet establish whether the current counterexample is identical to the earlier deferred defect.
Expected behavior and follow-up
Live-query architecture, law 9 and “Replay participants and failure” requires a failed or still-held replay to retain the last complete publication. Identify which acquisition still holds or fails the barrier at the recorded cut, and discriminate a production publication defect from any model or observation-cut defect before changing either one.
This is the same owner and retention comparison as the shared-source replay with late include demand already deferred from the RC. That record preserves another baseline failure at seed 521312968, path 255:3:3:8:11:9.
Preserve both traces in the shared model/driver comparison, extend generated reach for late include demand and held replacements, and include success/abort/failure neighbors before a production repair. A later successful random campaign does not close this defect.
The maintainer requested retaining this counterexample in a follow-up issue and restarting the release workflow. No test, comparison or run budget was weakened. #2290 addresses a separate source-health reach problem; it is not evidence that this retention failure is fixed. Related release preparation: #2171 and #2217.
- 主要言語
- TypeScript
- スター
- 4k
- フォーク
- 277
- 平均マージ
- 1日 7時間
- マージ済み PR（30日）
- 172
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
TanStack/db のほかの issue
-
難易度 1/5 1〜3時間 初心者へのやさしさ 88/100
メンテナーはふだん 1 日以内に返信
-
OfflineExecutor.dispose() never settles pendingTransactionPromises再び着手できるかも @Claire-ovo が 7 日前に担当しましたが、オープン中のプルリクエストはありません。 オープン
難易度 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 が 5 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
setWindow publishes the new page before its include demand settles (on-demand materialize / toArray)オープン
難易度 4/5 3〜5日 初心者へのやさしさ 30/100
メンテナーはふだん 1 日以内に返信
似ている issue
-
🐛 bug
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
LibreChat-AI/LibreChat#17733 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
TypeStrong/typedoc#3150 ·
-
accessibility bug good first issue
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
メンテナーはふだん 1 日以内に返信
-
Normalize image-source MIME types before SVG dispatch対応中かも @HarsH-1877 が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
tscircuit/image-utils#58 · コメント 1 件 ·
-
難易度 1/5 1時間未満 初心者へのやさしさ 74/100
メンテナーはふだん 2 日以内に返信