fix(CLI): cdk diff stack deletion causes a race condition

[comcalvi]

Co-authored by: @scanlonp

Issue # (if applicable)

Closes #29265.

Reason for this change

Creating a changeset for a stack that has not been deployed yet causes CFN to create a stack in state REVIEW_IN_PROGRESS. Previously we deleted this empty stack, but did not wait for the stack status to be DELETE_COMPLETE. This allowed cdk diff to exit while the stack status was still DELETE_IN_PROGRESS, which can cause subsequent CDK commands to fail, because a stack deletion operation is still in progress.

Description of changes

No longer create the changeset if the stack doesn't exist. Only perform the existence check if the changeset parameter is specified, to avoid a permission error when looking up a stack.

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

[TheRealAmazonKendra]

Correct me if I'm wrong here, but since we reverted #29485, if this is a cdk migrate based stack, we will now always tell customers that we are creating new resources instead of importing them. The original change was to prevent this very thing.

[TheRealAmazonKendra]

I think the correct fix here is mostly what @scanlonp did in #29394. The one piece that would have prevented the role switch here was if in packages/aws-cdk/lib/cdk-toolkit.ts, instead of

      const stackExistsOptions = {
        stack: stacks.firstStack,
        deployName: stacks.firstStack.stackName,
      };

      const stackExists = await this.props.deployments.stackExists(stackExistsOptions);

      const changeSet = (stackExists && options.changeSet) ? await createDiffChangeSet({

The change had been:

      const changeSet = options.changeSet && (await this.props.deployments.stackExists(stackExistsOptions) ? await createDiffChangeSet({

Because the if statement will exit if options.changeSet if false before looking up whether or not the stack exists.

[scanlonp]

Looks good to me.

Only comments would be:

• is there a functional difference in doing a try catch block in cleanupOldChangeset() as opposed to checking the exists parameter, or is this just for code clarity?
• If we have a migrate stack, it will not exist beforehand, so the logic could be streamlined. But it is not blocking and I am good with how it is.

[comcalvi]

is there a functional difference in doing a try catch block in cleanupOldChangeset() as opposed to checking the exists parameter, or is this just for code clarity?

turns out that deleteChangeset will throw if the stack doesn't exist. This was preventing a changeset from being created for me at some point, but that was because I was creating a changeset when a stack didn't exist, which is the wrong behavior. I've removed this.

If we have a migrate stack, it will not exist beforehand, so the logic could be streamlined. But it is not blocking and I am good with how it is.

I think I've altered the logic you're referring to, it should be more clear now.

[scanlonp]

Good to approve from me! I'll wait for Kendra to take a look.

Minor nit on the debug message.

[comcalvi]

test pipeline deployment is complaining there's no review...

[aws-cdk-automation]

➡️ PR build request submitted to test-main-pipeline ⬅️

A maintainer must now check the pipeline and add the pr-linter/cli-integ-tested label once the pipeline succeeds.

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: 610ae5d
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).