cdk deploy --revert-drift fails with CloudFormation "Internal Failure" after hotswapping SQS / DynamoDB properties

[pahud]

Describe the bug

After hotswapping a property that goes through the generic Cloud Control (CCAPI) path — SQS VisibilityTimeout or DynamoDB ProvisionedThroughput.ReadCapacityUnits — the follow-up cdk deploy --revert-drift fails at change-set creation with only Internal Failure from CloudFormation. Hotswaps that go through the dedicated Lambda handler (code, environment) do not trigger this; --revert-drift reconciles those fine.

A plain cdk deploy (no --revert-drift) on the same stack succeeds and brings the stack back in sync, and cdk validate --unstable=validate (online) also succeeds. So the template and stack are healthy; the failure is specific to the --revert-drift code path.

Regression?

Unknown — first time using --revert-drift.

Last known working version

n/a

Expected behavior

cdk deploy --revert-drift reconciles the hotswapped SQS / DynamoDB drift, the same way it does for hotswapped Lambda code and environment.

Current behavior

CdkWorkshopStack: creating CloudFormation changeset...
Failed to create change set cdk-deploy-change-set:
CdkWorkshopStack  (AWS::CloudFormation::Stack)
  Internal Failure

aws cloudformation describe-change-set on the failed change set returns Status: FAILED, StatusReason: Internal Failure — no further detail.

Reproduction steps

1. Deploy a stack with an SQS queue (visibilityTimeout: Duration.seconds(60)) and a provisioned DynamoDB table (default 5 RCU).
2. Change visibilityTimeout to Duration.seconds(90) (or readCapacity to 10) in code.
3. cdk deploy --hotswap → hotswapped! via the Cloud Control path. CLI then suggests --revert-drift on the next non-hotswap deploy.
4. cdk deploy --revert-drift → Internal Failure at change-set creation.
5. Control: cdk deploy (no flag) → succeeds and reconciles the drift.
6. Control: repeat steps 2–4 with a Lambda environment or code change instead → --revert-drift succeeds.

Either the SQS or the DynamoDB change alone is enough to reproduce.

Possible solution

Not verified, but the pattern (numeric properties on CCAPI-hotswapped resources fail; string-valued Lambda properties succeed) is consistent with a number/string type mismatch in how drift is detected or submitted for these resource types (VisibilityTimeout: 90 vs "90").

Additional information / context

• The --hotswap output actively points users at --revert-drift, so this is the first thing they try and the error gives no hint that a plain cdk deploy works.
• Stack was UPDATE_COMPLETE, StackDriftStatus: NOT_CHECKED, bootstrap version 32, before running --revert-drift.

CDK CLI Version

2.1143.0 (build 9c6bd0e)

CDK library version

aws-cdk-lib 2.271.0

Environment details (OS name and version, etc.)

Linux (AWS Code Editor on EC2), Node.js 24, us-east-1