Cassandra: data-plane requests during a DeleteTable answer 500 once the base data table is dropped #600

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.