Disabling a stream does not close its shards or change its status #482

What DynamoDB does

Measured 2026-10-24 between 00:29 and 00:46 UTC in us-east-1, on a table with a NEW_AND_OLD_IMAGES stream and three items, client retries off:

• UpdateTable StreamEnabled=false: DescribeStream on the stream ARN reports DISABLED 10 s later, and every one of the four shards now carries an EndingSequenceNumber (none had one while the stream was ENABLED). The old stream ARN stays describable.
• Reading each closed shard from TRIM_HORIZON: the response that carries a shard's last records omits NextShardIterator, and a shard with no records answers an empty page without NextShardIterator.
• UpdateTable StreamEnabled=true afterwards: a new stream ARN with a new label and four new shard ids, none shared with the old stream, which stays readable as DISABLED.

What ExtendDB does

The same sequence on a SQLite server: after StreamEnabled=false, DescribeTable shows the stream disabled, but DescribeStream on the stream ARN still reports ENABLED, no shard gets an EndingSequenceNumber, and every GetRecords keeps returning a NextShardIterator, so a consumer that reads until the iterator is absent never finishes. Nothing in the SQLite or PostgreSQL backend writes stream_shards.ending_sequence_number.

Measured on a build of #372's head, which does not change the disable path; main has the same code. PostgreSQL has the same writes and was checked on the same build.

Effect

A consumer that treats a missing NextShardIterator as the end of a shard, which is how the service signals a closed shard, polls a disabled stream forever.

Fix direction

On disable, set the stream's status to DISABLED and give every open shard an EndingSequenceNumber (its last written sequence number, or its starting number when empty), and on re-enable create a new stream with new shards. #372 already returns the terminal GetRecords response once a shard is closed and drained, so the two fit together.