(cli): Detect when attempting to bootstrap with older bootstrap version

[aamielsan]

Describe the bug

Hi, we're encountering a weird issue ever since upgrading to v.2.60.0. We think that this change in v.2.54.0 started the cause.

Given an account bootstrapped using CDK toolkit v2.54.0+, developers using a CDK toolkit version older than v2.54.0 will create a change set for the toolkit stack and will try to update the toolkit stack (essentially trying to downgrade the toolkit stack)

This creation of change sets leads to change sets conflict when developers / CI are running bootstrap in parallel.

Sample error message when developers/builds run in parallel:

sit-toolkit: creating CloudFormation changeset...

[2023-01-18T19:27:49.575Z]  ���  Environment aws://REDACTED/eu-north-1 failed bootstrapping: AlreadyExistsException: ChangeSet cdk-deploy-change-set cannot be created due to a mismatch with existing attribute ClientToken

Expected Behavior

Developers running cdk bootstrap without a --force option and using a CDK toolkit version older than the CDK toolkit version used to bootstrap the account should receive a warning:

Not downgrading existing bootstrap stack from version 'X+n' to version 'X'

And not proceed to creating a change set and updating the toolkit stack.

Current Behavior

There is no warning and developers using an older CDK toolkit version are able to create a change set and try to update the deployed toolkit stack.
This leaves the deployed CDK toolkit stack in a constant flux of upgrading and downgrading and creating change sets when some developers are using v.2.54.0+ and some developers are using older versions than v.2.54.0

Reproduction Steps

1. Install a CDK toolkit newer or equal to v2.54.0: npm -g aws-cdk@2.54.0
2. Bootstrap an account: cdk bootstrap --toolkit-stack-name test-toolkit
3. Check the deployed toolkit stack in CloudFormation
4. Note the new UseExamplePermissionsBoundary Parameter
5. Install a CDK toolkit older than v2.54.0: npm -g aws-cdk@2.53.0
6. Bootstrap the same account: cdk bootstrap --toolkit-stack-name test-toolkit
7. A changeset is still created without showing any warning:

Not downgrading existing bootstrap stack from version 'X+n' to version 'X'

The issue shows where there happen to be two developers doing steps 5-8 in parallel

Possible Solution

• Increment the CdkBootstrapVersion SSM Parameter value in the packages/aws-cdk/lib/api/bootstrap/bootstrap-template.yaml (?)
• OR enable developers to provide a change set name during bootstrap

Additional Information/Context

No response

CDK CLI Version

2.54.0

Framework Version

No response

Node.js Version

v16.16.0

OS

macOS Monterey

Language

Java

Language Version

Java 11

Other information

No response

[peterwoodworth]

Thanks for this request, this would be a nice feature to have.

I am marking this issue as p2, which means that we are unable to work on this immediately.

We use +1s to help prioritize our work, and are happy to revaluate this issue based on community feedback. You can reach out to the cdk.dev community on Slack to solicit support for reprioritization.

Check out our contributing guide if you're interested in contributing yourself

[adam-nielsen]

I just encountered this problem when I tried to deploy a normal stack (not bootstrapping) that was using CDK v2.45.0:

my-stack: creating CloudFormation changeset...

 ❌  my-stack failed: AlreadyExistsException: ChangeSet cdk-deploy-change-set cannot be created due to a mismatch with existing attribute ClientToken
    at Request.extractError (node_modules/aws-sdk/lib/protocol/query.js:50:29)
    at Request.callListeners (node_modules/aws-sdk/lib/sequential_executor.js:106:20)
    at Request.emit (node_modules/aws-sdk/lib/sequential_executor.js:78:10)
    at Request.emit (node_modules/aws-sdk/lib/request.js:686:14)
    at Request.transition (node_modules/aws-sdk/lib/request.js:22:10)
    at AcceptorStateMachine.runTo (node_modules/aws-sdk/lib/state_machine.js:14:12)
    at node_modules/aws-sdk/lib/state_machine.js:26:10
    at Request.<anonymous> (node_modules/aws-sdk/lib/request.js:38:9)
    at Request.<anonymous> (node_modules/aws-sdk/lib/request.js:688:12)
    at Request.callListeners (node_modules/aws-sdk/lib/sequential_executor.js:116:18) {
  code: 'AlreadyExistsException',
  time: 2023-06-28T01:28:46.746Z,
  requestId: 'bc072c2e-d36b-4a93-92d5-896c4ce58684',
  statusCode: 400,
  retryable: false,
  retryDelay: 659.0294361417568
}

 ❌ Deployment failed: Error: Stack Deployments Failed: AlreadyExistsException: ChangeSet cdk-deploy-change-set cannot be created due to a mismatch with existing attribute ClientToken
    at deployStacks (node_modules/aws-cdk/lib/deploy.ts:61:11)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at CdkToolkit.deploy (node_modules/aws-cdk/lib/cdk-toolkit.ts:314:7)
    at initCommandLine (node_modules/aws-cdk/lib/cli.ts:357:12)

Stack Deployments Failed: AlreadyExistsException: ChangeSet cdk-deploy-change-set cannot be created due to a mismatch with existing attribute ClientToken

The problem was fixed by upgrading the CDK packages to the latest version (v2.85.0 as I write this), so I only mention this because it seems to cause normal deploys to break as well, even if you're not doing anything with bootstrapping.