(cli): cdk diff will create an empty stack in REVIEW_IN_PROGRESS if run against an account the stack is not deployed to

[SamStephens]

Describe the bug

cdk diff will create an empty stack in REVIEW_IN_PROGRESS if run against an account the stack is not deployed to. I don't think there's anything you can do with the stack in this state except for delete it again.

Looking through past issues about this, it seems that the stack should be deleted after this happens, but I'm not seeing that.

Regression Issue

• Select this option if this issue appears to be a regression.

Last Known Working CDK Library Version

No response

Expected Behavior

cdk diff to leave my stacks untouched

Current Behavior

cdk diff results in a phantom stack

Reproduction Steps

cdk diff a stack against an account it is not present in.

Possible Solution

No response

Additional Information/Context

No response

AWS CDK Library version (aws-cdk-lib)

Multiple versions (I've had this with several stacks)

AWS CDK CLI version

2.1120.0 (build acefbf8)

Node.js Version

v24.13.0

OS

Linux Min 22.3

Language

Python

Language Version

3.11.14

Other information

No response

[pahud]

Thank you for reporting this.

History:
The original fix (aws/aws-cdk#29492, merged 2024-03-19) prevented changeset-based diff for stacks that don't exist in CloudFormation.

During the CLI refactoring into @aws-cdk/toolkit-lib, this guard was not carried over.
aws/aws-cdk-cli#1296 (merged 2026-04-01) partially addressed this by treating REVIEW_IN_PROGRESS stacks as non-existent for changeset type selection — so repeated cdk diff no longer fails.

What remains unfixed (confirmed via latest main source):

The first cdk diff --method=change-set against a non-deployed stack still creates a REVIEW_IN_PROGRESS ghost stack. The cleanupOldChangeset() function only deletes the changeset, not the stack:

aws-cdk-cli/packages/@aws-cdk/toolkit-lib/lib/api/deployments/cfn-api.ts

Lines 380 to 393 in acefbf8

	async function cleanupOldChangeset(
	cfn: ICloudFormationClient,
	ioHelper: IoHelper,
	changeSetName: string,
	stackName: string,
	) {
	// Delete any existing change sets generated by CDK since change set names must be unique.
	// The delete request is successful as long as the stack exists (even if the change set does not exist).
	await ioHelper.defaults.debug(`Removing existing change set with name ${changeSetName} if it exists`);
	await cfn.deleteChangeSet({
	StackName: stackName,
	ChangeSetName: changeSetName,
	});
	}

After the changeset is consumed, cleanupOldChangeset is called again but still only removes the changeset:

aws-cdk-cli/packages/@aws-cdk/toolkit-lib/lib/api/deployments/cfn-api.ts

Line 368 in acefbf8

await cleanupOldChangeset(options.cfn, ioHelper, options.changeSetName, options.stack.stackName);

The REVIEW_IN_PROGRESS check added by #1296 determines changeset type but does not clean up the ghost stack:

aws-cdk-cli/packages/@aws-cdk/toolkit-lib/lib/api/deployments/cfn-api.ts

Lines 272 to 274 in acefbf8

	const stack = await CloudFormationStack.lookup(cfn, options.stack.stackName, false);
	// A stack in REVIEW_IN_PROGRESS was created by a previous CREATE changeset
	// that was never executed. Treat it as non-existent for changeset purposes.

Workaround: Use --method=template to avoid changeset creation entirely:
cdk diff --method=template

The remaining fix would be to either:
Skip changeset diff for non-deployed stacks entirely (fall back to template diff), or
Delete the REVIEW_IN_PROGRESS stack after the diff changeset is consumed.

Making this a p1 for team's review.

[mrgrain]

Thanks for the report!

I don't think there's anything you can do with the stack in this state except for delete it again.

You can deploy the stack, so there's no need to delete it other than cleaning up (which I understand is desirable).

The remaining fix would be to either:
Skip changeset diff for non-deployed stacks entirely (fall back to template diff), or
Delete the REVIEW_IN_PROGRESS stack after the diff changeset is consumed.

We are not going to skip change sets. Change sets are strictly more powerful, but yes they came with "strings attached".

[mrgrain]

Yeah, I think we need to bring this back

https://github.com/aws/aws-cdk/pull/29492/changes#diff-0a687a33d773a0ab15ac5b7f5f87613a7637754dbdacaa6fa90ac107681b49efL397-L407