Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Cassandra: a transaction completed by the recovery worker writes no index rows and no stream record

Đang mở
  • Có gì không ổn?
#579 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
43/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
cassandra, rust
Lĩnh vực
backend, databases

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

backend:cassandra bug

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.

Ngôn ngữ chính
Rust
Star
517
Fork
60
Merge trung bình
2 ngày 23 giờ
Pull request đã merge (30 ngày)
25

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của ExtendDB/extenddb

Tất cả issue của ExtendDB/extenddb

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.