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: TransactWriteItems Delete removes no index rows and a key-changing Put leaves the old index row

Đang mở
  • Có gì không ổn?
#568 1 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

@LeeroyHannigan đang làm issue này rồi.

Từ ngày 21/10/2026.

  • #424 của @LeeroyHannigan — đang mở

Đánh giá

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

Hướng nghiên cứu

Read crates/storage-cassandra/src/data/transactions.rs, starting at commit_single_operation and the Put and Delete arms; compare their index syncing with the Update arm and the single-item paths. Add storage tests for GSI and LSI rows after a key-changing Put and Delete, plus the dual-target wire test described in the issue. The related recovery path is explicitly larger scope; the linked open pull request indicates work is already underway.

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 TransactWriteItems Delete removes no GSI or LSI index rows, and a TransactWriteItems Put that changes an item's index key leaves the old index row in place. A Query on the index then returns the deleted item, or returns the item under both its old and its new key, with the stale copy's whole projection. The single-item DeleteItem, PutItem and UpdateItem paths maintain the index correctly on the same table, and the transacted Update does too.

Measured 2026-10-25 on a server built from main 744ea291 against a cassandra:4.1 node, index_propagation_delay_ms 0, index ACTIVE before the first write, each index query polled for 30 s:

Step on Cassandra Query old index key Query new index key Expected
transacted Put of X with gsi_pk=g1 n/a 1 item in 0.02 s row written
transacted Put of X with gsi_pk=g2 1 item after 30 s 1 item old row gone
transacted Delete of X 1 item after 30 s 1 item after 30 s both gone
transacted Update SET gsi_pk=u2 (seeded u1) 0 items 1 item correct
transacted Delete after that Update n/a 1 item after 30 s row gone
single-item PutItem, key-changing PutItem, UpdateItem, DeleteItem correct at every step, inside 0.02 s

The base row is gone after each delete (ConsistentRead GetItem returns nothing), so this is index state only. SQLite is correct on every step of both paths.

Amazon DynamoDB, same sequence on 2026-10-25 (table with one GSI, projection ALL): after the transacted Put with the changed key the old key's query is 0 and the new key's is 1; after the transacted Delete both are 0; all within 4 s of the write.

Cause

crates/storage-cassandra/src/data/transactions.rs, commit_single_operation: the Put arm passes None as the old image to the index sync, so sync_indexes has nothing to delete when the index key changed; the Delete arm never calls the index sync at all. The Update arm passes the commit-time read as the old image, which is why it is correct. The single-item paths pass the pre-mutation item in every case.

Fix shape

Pass the operation's pre-image (PREPARE reads it and carries it as pre_commit_item_data; the stream-record change on the same path consumes it the same way) as the old image for the Put arm, and call the index sync with (Some(pre_image), None) for the Delete arm so the old rows are removed. Storage test per arm on a table with a GSI and an LSI asserting the index rows after a key change and after a delete, plus a dual-target wire test querying the index after a transacted Delete.

Related

Recovery after a crash (recover_commit_op) syncs no index rows for any arm and writes no stream record; same file, same shape of fix, larger scope.

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.