Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#568 コメント 1 件 リアクション 0 件 担当者 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日 23時間
マージ済み PR（30日）
25

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

ExtendDB/extenddb のほかの issue

ExtendDB/extenddb の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。