Requests during a table's DELETING window answer differently from DynamoDB #505

Summary

While a table is DELETING, ExtendDB answers four requests differently from DynamoDB. The service reports the window as a table that is still there and in use; ExtendDB reports it as a table that does not exist, or with a different sentence.

Measured on the service 2026-10-24 09:30 UTC (two repeats, identical) and on ExtendDB with the PostgreSQL backend at main 744ea29 and on #504, with the window held open by an ACCESS SHARE lock on the table's data table. The other backends are not measured here.

DescribeTable (TableStatus DELETING) and CreateTable with the name (ResourceInUseException Table already exists: <name>) match the service.

Cause

crates/storage-postgres/src/delete_table.rs selects the row WHERE ... table_status IN ('ACTIVE', 'CREATING'), so a DELETING row reads as TableNotFound. update_table.rs locks the row and answers TableNotActive for any status other than ACTIVE, which the engine words as Table <name> is not in ACTIVE state. The data-plane table lookup excludes DELETING rows, so reads and writes answer ResourceNotFoundException until the row is gone.

Fix shape

For the two control-plane requests, look the name up without the status filter when the filtered select returns nothing and answer a DELETING row with the service's sentence; delete_table.rs already does this for a table that is being restored. For the data plane, the service serves reads and writes until the table is gone, so the lookup would include DELETING rows; whether writes during the window should be served or refused is a design question, since a write that lands between the data drop and the row delete is lost on both sides.

With the default delete delay the window on ExtendDB lasts as long as the data drop takes, so a client only sees it when another connection holds a lock on the table's data.

Found while fixing #449 (#504).