Cassandra: a transaction completed by the recovery worker writes no index rows and no stream record
メンテナーはふだん 2 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 43/100
調査の方向性
Start with recover_commit_op and the live commit path in crates/storage-cassandra/src/data/transactions.rs, then trace LedgerOp, commit_secondary_effects, stream_record_statement, and sync_indexes. Add recovery coverage that prepares a transaction, applies the base LWT, drops the engine, and runs recovery; done means the recovered item has its index rows and stream record.
索引モデルが issue の本文から書いたものです。
説明
Summary
On the Cassandra backend a transaction completed by the recovery worker after a crash writes its items and nothing else: no GSI or LSI index rows and no stream record. Read from recover_commit_op in crates/storage-cassandra/src/data/transactions.rs at main 744ea291; unchanged by #576, which adds the stream record to the live commit path only.
Mechanism
recover_commit_op replays the base mutation from the ledger (UPDATE ... SET item_data = ?, prepared_txn_id = NULL ... for PUT and UPDATE, the two-step delete for DELETE) and calls neither the index sync nor the stream record builder. The ledger's LedgerOp carries the keys, the item data and the pre-commit image (pre_commit_item_data), but not the stream capture (view type, region) or the table's key schema, both of which stream_record_statement and sync_indexes need.
The window is the one between the base-row LWT and the secondary-effects LOGGED BATCH in the live commit path (commit_single_operation then commit_secondary_effects). A crash there leaves the item written and the ledger in COMMITTING; recovery finishes the item and skips the rest. The gap is permanent and silent: a stream consumer's view of that item is stale with nothing to signal it, and an index query misses or mis-returns the item until the next write to it.
Fix shape
Carry the capture on LedgerOp as an optional #[serde(default)] field (the ledger is already versioned by shape in that way for pre_commit_item_data), look the key info up by table_id from the catalog in recovery, and have recover_commit_op call the same commit_secondary_effects the live path calls, with the pre-image from pre_commit_item_data and the row's created_to_prepare and last_committed_txn_timestamp applied through the same old-image rule. A storage test that runs PREPARE and the base LWT, drops the engine before the secondary batch, runs recovery, and asserts the index rows and the stream record are present.
Related: #568 (the live commit path's index arms for Put and Delete), which the recovery change should land after so recovery and the live path share one function.
- 主要言語
- Rust
- スター
- 517
- フォーク
- 60
- 平均マージ
- 2日 23時間
- マージ済み PR（30日）
- 25
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
ExtendDB/extenddb のほかの issue
-
backend:mongodb bug
難易度 2/5 1〜3時間 初心者へのやさしさ 77/100
メンテナーはふだん 2 日以内に返信
-
backend:cassandra bug
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 2 日以内に返信
-
documentation
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 2 日以内に返信
-
backend:cassandra bug
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
メンテナーはふだん 2 日以内に返信
-
[storage.cassandra] accepts unknown keys silently対応中かも @LeeroyHannigan が 3 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
ExtendDB/extenddb#540 · 担当者 1 名 ·
メンテナーはふだん 2 日以内に返信
ExtendDB/extenddb の issue をすべて見る
似ている issue
-
desktop documentation
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
vfarcic/dot-agent-deck#2008 ·
メンテナーはふだん 1 日以内に返信
-
needs triage
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
pbakaus/impeccable#1210 ·
メンテナーはふだん 1 日以内に返信
-
area: ci priority: P4 ready-for-agent
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
shep-pm/shep#1249 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
L: javascript
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
dependabot/dependabot-core#16744 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
nautechsystems/nautilus_trader#5486 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信