Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#579 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
43/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
cassandra, rust
Ambito
backend, databases

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Rust
Stelle
517
Fork
60
Merge medio
2g 23h
PR unite (30g)
25

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ExtendDB/extenddb

Tutte le issue di ExtendDB/extenddb

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.