Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Cassandra: TransactWriteItems Delete removes no index rows and a key-changing Put leaves the old index row

未关闭
  • 哪里不对？
#568 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 2 天内回复

@LeeroyHannigan 已经在做这个了。

开始于 2026年10月21日。

  • #424 来自 @LeeroyHannigan —— 未关闭

评估

难度
3/5
预计耗时
1-2 天
新手友好度
35/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
停滞
技术栈
cassandra, rust
领域
database, databases

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
Rust
星标
517
派生
60
平均合并
2 天 22 小时
30 天内合并 PR
25

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

ExtendDB/extenddb 的其他 Issue

查看 ExtendDB/extenddb 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。