Cassandra: a transaction completed by the recovery worker writes no index rows and no stream record
维护者通常 2 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 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 天 22 小时
- 30 天内合并 PR
- 25
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
ExtendDB/extenddb 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 2 天内回复
-
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 天内回复
查看 ExtendDB/extenddb 的全部 Issue
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 78/100
swc-project/swc-next#1165 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 73/100
Alive24/shea-symphony#574 ·
-
documentation good first issue help wanted
难度 2/5 1-3 小时 新手友好度 74/100
dev-five-git/devup-ui#879 ·
维护者通常 11 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 77/100
farion1231/cc-switch#9038 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 85/100
FalkorDB/FalkorDB#3597 · 1 条评论 ·
维护者通常 2 天内回复