AWS::DynamoDB::GlobalTable: a table-level on-demand ceiling may be permanently stranded across a PROVISIONED round-trip (needs a probe)

[go-to-k]

Raised by the code review of PR #1439, which added the table-level on-demand
ceiling reset.

That reset is deliberately suppressed unless the table is PAY_PER_REQUEST on
BOTH sides of the deploy (onDemandCeilingLive), because sending
OnDemandThroughput on a provisioned table is a ValidationException. The open
question the reviewer raised is what happens to a ceiling that was live before a
flip TO PROVISIONED:

1. Deploy A: PAY_PER_REQUEST + WriteOnDemandThroughputSettings.MaxWriteRequestUnits: 200.
2. Deploy B: flips to PROVISIONED and drops the block. The reset is suppressed
   (correctly — the field is meaningless on a provisioned table).
3. Deploy C: flips back to PAY_PER_REQUEST, still with no block. previousProperties
   is now deploy B's template, which carries no WriteOnDemandThroughputSettings,
   so the reset never fires.

If DynamoDB RETAINS the table-level OnDemandThroughput across the flip to
PROVISIONED and restores it on the flip back, the 200 ceiling resurfaces at
step 3 with nothing in the template asking for it, and no subsequent deploy can
clear it — the exact silent-stale-ceiling outcome #1434 set out to remove, just
reached by a longer path.

If AWS instead DROPS the member on the flip to PROVISIONED, there is nothing to
strand and this issue can be closed as not-a-bug.

This is unresolved, not assumed

It was NOT settled by the #1434 probes: that run cleared the table-level ceiling
({MaxReadRequestUnits: -1}) BEFORE flipping to PROVISIONED, so the readback
after the flip says nothing about retention.

How to settle it

One probe, on a throwaway table:

1. CreateTable PAY_PER_REQUEST with OnDemandThroughput: {MaxWriteRequestUnits: 200}.
2. UpdateTable BillingMode: PROVISIONED + ProvisionedThroughput.
3. DescribeTable — is OnDemandThroughput still reported?
4. UpdateTable back to PAY_PER_REQUEST, sending NO OnDemandThroughput.
5. DescribeTable — did the 200 come back?

Note the probe hazard recorded on #1434: do NOT probe reset shapes with an empty
container ({}) on this type — it was accepted and then wedged a global table in
UPDATING for over an hour, leaving an orphan AWS refused to delete for 24h.
This probe only needs value-shaped payloads, so it is safe.

If retention is confirmed

The fix is probably to compare against the last known ON-DEMAND-era desired
state rather than the immediately-previous template, or to re-assert the reset
on the flip back to PAY_PER_REQUEST when AWS reports a ceiling that no
template declares (an observed-state-driven reset rather than a diff-driven
one).

[go-to-k]

Claiming the PROBE half of this issue (no code changes, no files touched) so it does not
collide with the parallel lanes on dynamodb-globaltable-provider.ts. I will run the
value-shaped round-trip probe described above on a throwaway single-region table
(no replica, so the 24h replica deletion lock recorded on #1434 does not apply) and post
the transcript here. If AWS drops the ceiling on the flip to PROVISIONED this can be
closed as not-a-bug; if it retains it, the fix itself stays unclaimed for whoever holds
the provider file next.

[go-to-k]

Probe result: AWS DROPS the ceiling on the flip — nothing can be stranded

Ran the exact probe this issue specifies, against real AWS (us-east-1,
2026-08-10), on a throwaway single-region table cdkd-1441-probe-1786301893.
No replica was ever added, so the 24h replica-deletion lock recorded on #1434
did not apply, and only value-shaped payloads were sent (never the empty
container that wedged a table for an hour during the #1434 probes). The table
was deleted at the end and the deletion confirmed.

Transcript

1. CreateTable PAY_PER_REQUEST with OnDemandThroughput.MaxWriteRequestUnits: 200

{"Billing": "PAY_PER_REQUEST", "OnDemand": {"MaxWriteRequestUnits": 200}, "Prov": {"R": 0, "W": 0}}

2-3. UpdateTable -> PROVISIONED (5/5), sending NO OnDemandThroughput, then DescribeTable

{"Billing": "PROVISIONED", "OnDemand": null, "Prov": {"R": 5, "W": 5}}

OnDemandThroughput is absent — AWS dropped the member on the flip rather
than retaining it.

4-5. UpdateTable back to PAY_PER_REQUEST, sending NO OnDemandThroughput, then DescribeTable

{"Billing": "PAY_PER_REQUEST", "OnDemand": null, "Prov": {"R": 0, "W": 0}}

The 200 did not come back.

Conclusion

This issue's "if retention is confirmed" branch does not apply: DynamoDB does
not retain the table-level OnDemandThroughput across a PROVISIONED
round-trip, so there is nothing for the suppressed reset to strand. The
deploy-A / deploy-B / deploy-C sequence in the issue body ends with no ceiling
live on AWS and none declared in the template — which is the correct end state
and already what cdkd produces today.

The onDemandCeilingLive suppression added by PR #1439 therefore needs no
companion change, and no observed-state-driven reset is required.

Closing as not-a-bug per the issue's own "If AWS instead DROPS the member on
the flip to PROVISIONED, there is nothing to strand and this issue can be
closed as not-a-bug."