Cassandra: data-plane requests during a DeleteTable answer 500 once the base data table is dropped
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
- 45/100
Direzione di ricerca
Read crates/engine/src/delete_table.rs to trace when the key-info cache is invalidated relative to delete_table returning. Compare the Cassandra behavior with the PostgreSQL handling from #550 and the backend question in #505. Done means data-plane requests during the DELETING window no longer return 500; the issue leaves open whether to return 404 or 200.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Summary
On Cassandra, DeleteTable drops the data tables inside the request. With the server's key-info cache warm, GetItem, PutItem, Query and Scan on the table answer 500 InternalServerError from the moment the base data table is dropped until the catalog row is removed and the cache entry is invalidated. Amazon DynamoDB answers 200 for the whole of its DELETING window.
Measured (Cassandra 4.1, 2026-10-26)
A four-GSI table, GetItem every 20 ms through a live DeleteTable: 200 until the base drop, then 500 for 3.7 to 4.6 s (the index drops), then 404 once the row is gone. Three runs, the same on main and on #598. With a cold cache the whole window answers 404 (the key-info read maps DELETING to not found on this backend, the #505 settlement).
Notes
The engine invalidates the key-info entry only after delete_table returns (crates/engine/src/delete_table.rs). Invalidating it at the claim, or mapping the dropped-table CQL error to ResourceNotFoundException as PostgreSQL does since #550, would turn the 500 into the 404 the cold path already gives. Serving 200 as the service does is the #505 question for this backend.
- Lingua principale
- Rust
- Stelle
- 517
- Fork
- 60
- Merge medio
- 2g 22h
- PR unite (30g)
- 25
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di ExtendDB/extenddb
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 2 giorni
-
backend:mongodb bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 77/100
I maintainer di solito rispondono entro 2 giorni
-
backend:cassandra bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 2 giorni
-
documentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 2 giorni
-
backend:cassandra bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
I maintainer di solito rispondono entro 2 giorni
Tutte le issue di ExtendDB/extenddb
Issue simili
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
swc-project/swc-next#1165 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 73/100
Alive24/shea-symphony#574 ·
-
bug tests Windows
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
documentation good first issue help wanted
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
dev-five-git/devup-ui#879 ·
I maintainer di solito rispondono entro 11 giorni
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 77/100
farion1231/cc-switch#9038 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno