[LeeroyHannigan]

Fixes #552 and #551. The branch is based on #550 (fix/505-deleting-window-answers), which adds the Table is being deleted sentence; it targets main once #550 is merged.

While a table is DELETING, Amazon DynamoDB answers these calls as follows, on the table and on the Amazon Resource Name (ARN) of its stream, measured 2026-10-25 and 2026-10-26:

Call	On the table	On the table's stream ARN
DescribeTimeToLive	400 ValidationException "Cannot describe time to live while table is in DELETING state: Current table state is DELETING"
UpdateTimeToLive	200, with the rules it applies to an ACTIVE table
TagResource, UntagResource	400 ResourceInUseException "Attempt to change a resource which is still in use: Table is being deleted: "	200
ListTagsOfResource	200 with the tags	200 with the stream's tags

DescribeTimeToLive on a CREATING table answers the same ValidationException with CREATING in the sentence, and is served on an UPDATING table.

ExtendDB now answers these calls this way on PostgreSQL, SQLite, MongoDB and Cassandra. Before, UpdateTimeToLive answered "Table is not in ACTIVE state", DescribeTimeToLive answered 200, and the tag calls answered ResourceNotFoundException on MongoDB and Cassandra while PostgreSQL and SQLite accepted both writes.

How it works:

• The engine reads the table's status with describe_table. TableKeyInfo has no status, and the MongoDB and Cassandra key-info reads report a DELETING row as not found, so the tag path reads the status before the key-info read.
• update_ttl admits DELETING beside ACTIVE on every backend.
• For a table it read as DELETING, UpdateTimeToLive sends no data definition language (DDL) statements for the index, because the delete removes the data table or collection with its index. On PostgreSQL a disable's DROP INDEX waited with no lock timeout behind any holder of the data table, and the table's reads and writes queued behind it. On MongoDB an enable's create_index could create the dropped collection again. MongoDB create_ttl_index also reads an ACTIVE catalog document only.
• The tag write refusal applies to the table's ARN. On the service a stream's tags stay with the stream, which it keeps describable after the table is gone (A disabled stream of a deleted table stays describable on the service #518).

Catalog cost: the status read is four catalog queries on PostgreSQL and SQLite and two on MongoDB and Cassandra, once per DescribeTimeToLive, UpdateTimeToLive, TagResource, UntagResource and ListTagsOfResource call. The tag path keeps the key-info read after it for every status but DELETING, so a tag call on an ACTIVE table sends seven queries before its tag statements on PostgreSQL and SQLite (three before this change) and four on MongoDB and Cassandra (two before). These are control-plane calls; the item and batch paths are unchanged.

Differences from the service that remain:

• ListTagsOfResource returns the tags for the whole window on PostgreSQL and SQLite. On MongoDB it returns no tags once the delete call has removed them, and with storage-cassandra: two concurrent DeleteTable calls on one table both complete #553 Cassandra removes them in the last statements of the delete, after the drops. The service returns them for the whole window.
• The refusal removes tag writes admitted during the window. A write whose status read came before the delete can still be written after the delete removed the tag rows, as on main.
• For several seconds after a tag write the service refuses another tag write on the resource with LimitExceededException "Table tags are being updated: " (seven rows); a DeleteTable in that window was refused once with ResourceInUseException and the same sentence. ExtendDB has no such state.
• After the table is gone, ListTagsOfResource on its stream ARN answers ResourceNotFoundException here, where the service answers 200 with the stream's tags. Pre-existing, filed separately.
• ExtendDB does not validate tags. The service checks the tag key ("The Tag Key provided is invalid, Key: ") before the DELETING refusal.
• UpdateTimeToLive has no rate limit ("Time to live has been modified multiple times within a fixed interval"), a documented difference, and no attribute check ("TimeToLive is active on a different AttributeName: current AttributeName is "), which the service applies to the disable form too.
• On MongoDB an enable admitted while the table is ACTIVE can still create the data collection again, when its catalog read comes before DeleteTable marks the document and its create_index runs after the drop: 1 of 20 delete races through the API in one run and 0 of 80 in another, on a single-node replica set with this change; 4 of 20 on the base.

Tests:

• Engine unit tests for the DescribeTimeToLive gate with both sentences and for the tag write gate on table and stream ARNs.
• Storage tests on all four backends for update_ttl during the window. On PostgreSQL a disable through the handler leaves the Time to Live (TTL) index in place. On MongoDB an index build on a DELETING document creates no collection, and a test drives the five handlers over a MongoEngine with the document DELETING.
• Dual-target wire tests on a held PostgreSQL window for every row of the table above.
• devtools/run-mongodb-tests runs the ignored MongoDB window tests in continuous integration (CI).
• No test drives the handlers over SQLite or Cassandra inside the window; the skip of the index DDL is pinned by the PostgreSQL storage test.

Merge notes

With #553 (fix/553-cassandra-concurrent-delete-table): one conflict in tests/python/test_deleting_window_control_plane.py, where both branches append test classes at the same point; keep both blocks, this branch's two classes first, then TestConcurrentDeleteTable. crates/storage-cassandra/tests/direct/deleting_window.rs merges on its own.

With #543 (fix/438-get-records-round-trips): devtools/run-mongodb-tests, where both add a live-test step at the same place; the resolution is one step with --ignored records_live deleting_window.