cdk 2.1.0 synth, diff subcommands fail with "AssertDescription: CDK bootstrap stack version 6 required...". cdk 2.1.0 deploy subcommand succeeds.

[chowlett]

What is the problem?

cdk synth and cdk diff fail with "AssertDescription: CDK bootstrap stack version 6 required. Please run 'cdk bootstrap' with a recent version of the CDK CLI." after the template checks SSM for version not 1-5. The actual version in SSM is 9.

cdk deploy succeeds.

After the successful cdk deploy, the synth and diff continue to fail.

Reproduction Steps

1. Upgrade cdk 2.0.0 to 2.1.0
2. run cdk bootstrap with appropriate credentials
3. create a new folder and cd to it
4. create a new cdk project with cdk init --language typescript
5. cdk synth
6. cdk diff
7. cdk deploy

What did you expect to happen?

A clean synth with no errors displayed
A clean diff with no errors displayed
A clean deploy with no errors displayed

What actually happened?

for synth and diff

...
Rules:
  CheckBootstrapVersion:
    Assertions:
      - Assert:
          Fn::Not:
            - Fn::Contains:
                - - "1"
                  - "2"
                  - "3"
                  - "4"
                  - "5"
                - Ref: BootstrapVersion
        AssertDescription: CDK bootstrap stack version 6 required. Please run 'cdk bootstrap' with a recent version of the CDK CLI.

for deploy - a clean, error-free execution with a CFn template produced as expected.

CDK CLI Version

2.1.0

Framework Version

2.0.0

Node.js Version

16.10.0

OS

macOS Monterey (12.0.1)

Language

Typescript

Language Version

TypeScript 4.2.4

Other information

The bootstrap CDKToolkit stack looks as expected - all of the modern template trappings (the previous bootstrap was legacy). The value of the SSM parameter /cdk-bootstrap/hnb659fds/version is 9, as expected. The cdk-hnb659fds-deploy-role-<account>-<region> role has the appropriate ssm:GetParameter permission for .../cdk-bootstrap/hnb659fds/version. the cdk-hnb659fds-lookup-role-<account>-<region> role has ssm:Get* permission for *.

"old" cdk projects continue to function as expected with cdk synth etc.

Hoping you can deduce some bozo thing I must have overlooked or done. Thanks for whatever help you can provide.

[chowlett]

Correction - cdk diff may not failing. It reports the cdk version check rule under "Other Changes", at the end of its output. The output looks good otherwise.

Other Changes
[+] Unknown Rules: {"CheckBootstrapVersion":{"Assertions":[{"Assert":{"Fn::Not":[{"Fn::Contains":[["1","2","3","4","5"],{"Ref":"BootstrapVersion"}]}]},"AssertDescription":"CDK bootstrap stack version 6 required. Please run 'cdk bootstrap' with a recent version of the CDK CLI."}]}}

I had interpreted that as failure. Maybe it's not.

[ryparker]

Hey @chowlett 👋🏻

I'm not able to reproduce this on my end with CDK v2.1.0

Could you try deleting node_modules and if possible recreate your NPM/yarn lock file? Also make sure that all your CDK dependencies have the same version.

[chowlett]

Thanks @ryparker. I deleted node_modules and reinstalled the dependencies. cdk synth still fails with the same bootstrap version error. The cdk dependencies have the same version:

cdk app version

cdk --version
2.1.0 (build f4f18b1)

cdk dependency versions

 % npm list           
bootstrap-version-test@0.1.0  ...
├── @types/jest@26.0.24
├── @types/node@10.17.27
├── aws-cdk-lib@2.1.0
├── aws-cdk@2.1.0
├── constructs@10.0.10
├── jest@26.6.3
├── source-map-support@0.5.21
├── ts-jest@26.5.6
├── ts-node@9.1.1
└── typescript@3.9.10

What do you think about me destroying the CDKToolkit stack, re-bootsrapping, and recreating this repro? FWIW it feels to me like cdk synth is somehow fumbling the bootstrap version it reads from SSM. That's why I am wondering if re-bootsrapping might help.

[robertd]

@chowlett I also thought this was a bug. However, @njlynch pointed out that this is an expected behavior in v2.

@njlynch: This is part of the new-style stack synthesis, which is a feature that’s been around for a while, but wasn’t enabled by default on v1.

[chowlett]

@robertd thanks. My issue is that the feature seems not to be working correctly. The version check is "bootstrap version is not 1, 2, 3, 4, 5", i.e. version is >= 6. My bootstrap version is 9 (verified by inspecting the SSM parameter ../cdk-bootstrap/hnb659fds/version). So I should pass this check. But I am failing it. So the cdk variable "BootstrapVersion" that synch is checking must have the value 1, or 2, or 3, or 4, or 5. That value would be wrong.

Does that make sense? Thanks.

[robertd]

@chowlett I was confused too when I first saw it. Mainly because s3 bucket bootstrap version is at 9 as well. But I guess this is the part of the new-style stack synthesis.

@njlynch Would mind chiming in on this and clarifying the purpose of always seeing this new CheckBootstrapVersion rule going forward? Thanks! 😉

[njlynch]

Correction - cdk diff may not failing. It reports the cdk version check rule under "Other Changes", at the end of its output. The output looks good otherwise. [...] I had interpreted that as failure. Maybe it's not.
Would mind chiming in on this and clarifying the purpose of always seeing this new CheckBootstrapVersion rule going forward? Thanks!

CDK v2 enables the "new-style stack synthesizer" by default (e.g., DefaultStackSynthesizer), which was previously enabled for v1 by setting the @aws-cdk/core:newStyleStackSynthesis feature flag. The DefaultStackSynthesizer uses conventionally named roles and concrete asset storage locations, versus the LegacyStackSynthesizer, which has restricted cross-environment abilities and uses CloudFormation parameters for assets.

With the default synthesizer, the CheckBootstrapVersion rule is added to the Stack's template as a safety check, to verify that the bootstrap stack in the target environment meets the minimum requirements of the current stack. The AssertDescription being shown is the failure message a user would see on deploy if their bootstrap stack was not up-to-date. The inclusion of this element is not a failure, merely a new element for stacks that are being upgraded from the legacy synthesizer. It will show up in the diff until it is deployed, and then will only show up if there's a change, same as any other CloudFormation template element.

Hope that helps! Let me know if you have any follow-ups on that.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

[afreyermuth98]

Hello !

Have you found a solution @robertd @chowlett ?
I'm facing the same issue. When I bootstrap my account, it installs bootrap version 10 but my cdk deployment wants absolutely version 6. I tried to edit the cloudformation template to 6 but it installs 10 by default.
Moreover, is it possible to maybe skip the bootstrapping as it was with cdk v1 ?

Thanks by advance

[robertd]

@afreyermuth98 Checkout @njlynch 's comment above (#17942 (comment))

[ncaq]

I'm using
aws-cdk/packages/@aws-cdk/assertions at master · aws/aws-cdk
and encountered this error.
After looking at this issue and the following test code
aws-cdk/template.test.ts at master · aws/aws-cdk

context: { "@aws-cdk/core:newStyleStackSynthesis": false },

I tried as
As before, I get the following error.

Unable to find artifact with id "HogeStack".

Of course, deploying version 10 with cdk bootstrap and running the test code with newStyle enabled gives me an error.
How can I migrate my snapshot tests to v2?
The actual test code looks like this.
Each Stack is empty.

import { App } from "aws-cdk-lib";
import { Template } from "aws-cdk-lib/assertions";
import { FooStack } from "../lib/foo-stack";
import { HogeStack } from "../lib/hoge-stack";

test("snapshot", () => {
  const app = new App({
    context: { "@aws-cdk/core:newStyleStackSynthesis": false },
  });
  const fooStack = new FooStack(app, "FooStack");
  const fooTemplate = Template.fromStack(fooStack);
  expect(fooTemplate.toJSON()).toMatchSnapshot();
  const hogeStack = new HogeStack(app, "HogeStack");
  const hogeTemplate = Template.fromStack(hogeStack);
  expect(hogeTemplate.toJSON()).toMatchSnapshot();
});

[ncaq]

I thought it would be better if I didn't use the same App all the time, but in the actual production code, which is a bit more complex, a field in Stack a is dependent on a field in Stack b. So if I don't use the App all the time, I get an error.

[ncaq]

I've been doing some research and found out that the content of this issue is not relevant, so I'm going to create a new issue.

[joekiller]

One more necrobump... I had "this problem" with a pipelines stack that worked from from cli cdk deploy. In this case, the cdk project was in a subdirectory of the project and while I was building fine because I included in the commands cd cdk-dir I forgot to update the primaryOutputDirectory as well and overlooked the reason the build was failing.

        primaryOutputDirectory: 'cdk-build/cdk.out',   <--- forgot this
        commands: [
          'cd cdk-build',
          'npm ci',
          'npm run build',
          'npx cdk synth',
        ],

[vdanniel]

I am having the same issue.
What was a the find here?

[mpermana]

I am having the same issue with new linux installation. Can we reopen this issue. Been running cdk boostrap and cdk synth for a newly build app.

[pedro9bee]

I am facing the same problem. There is any workarround ?
I face the problem since I try to implement API Gateway.

[forresthopkinsa]

This is a pretty confusing thing to see when just starting with CDK. I get it now, but I would still consider it a UX bug.

[gaplo917]

I just had a fresh install of aws-cdk 2.25.0 from cdk init app --language typescript confirmed problem still exist.

...
Rules:
  CheckBootstrapVersion:
    Assertions:
      - Assert:
          Fn::Not:
            - Fn::Contains:
                - - "1"
                  - "2"
                  - "3"
                  - "4"
                  - "5"
                - Ref: BootstrapVersion
        AssertDescription: CDK bootstrap stack version 6 required. Please run 'cdk bootstrap' with a recent version of the CDK CLI.

from @njlynch's comment #17942 (comment)

It will show up in the diff until it is deployed, and then will only show up if there's a change, same as any other CloudFormation template element.

For the assertion issue also happen in cdk synth. So it is impossible to do the first deploy before I want to confirm what to be deployed by studying the output of cdk synth (synthesized CloudFormation template).

Workaround for typescript

For those who want to check the result before the first deploy, I suggest to temporarily add "@aws-cdk/core:newStyleStackSynthesis": false in your cdk.json

  "context": {
    "@aws-cdk/aws-apigateway:usagePlanKeyOrderInsensitiveId": true,
    "@aws-cdk/core:stackRelativeExports": true,
    "@aws-cdk/aws-rds:lowercaseDbIdentifier": true,
    "@aws-cdk/aws-lambda:recognizeVersionProps": true,
    "@aws-cdk/aws-cloudfront:defaultSecurityPolicyTLSv1.2_2021": true,
    "@aws-cdk-containers/ecs-service-extensions:enableDefaultLogDriver": true,
    "@aws-cdk/aws-ec2:uniqueImdsv2TemplateName": true,
    "@aws-cdk/core:checkSecretUsage": true,
    "@aws-cdk/aws-iam:minimizePolicies": true,
+    "@aws-cdk/core:newStyleStackSynthesis": false,
    "@aws-cdk/core:target-partitions": [
      "aws",
      "aws-cn"
    ]
  }

After that, I can get the output

[SantaHub]

Hahaha this is a very weird things. It took me some time to realize it wasnt an error and merely an attribute value. I highly recommend it not being the last line on the console

[mcqj]

Why not just fix the UX issue?

[bfrancom]

I saw this same thing. Wasn't sure what to think since the output doesn't show up in the examples on https://cdkworkshop.com/. Had to come here to see what was up.

[yuyokk]

This is a pretty confusing thing to see when just starting with CDK. I get it now, but I would still consider it a UX bug.

same here, created new stack and seeing this warning is weird dev experience.

[DavidSouther]

IF YOU ARE COMING HERE AND STILL NOT UNDERSTANDING THIS THREAD (because you scrolled too fast, like me, and missed @chesterm8's write up)

This is NOT an error. YOUR CODE IS FINE.

The cdk synth step creates a number of resources for your app. One of those resources is a check that the deploying tool has the correct version. This is an error that would happen, IF you ran cdk deploy with an out-of-date bootstrap. The AssertDescription would then be the error shown at that point.

This is a "UX" bug because it happens to be the last thing in the diff for the stack after synth, and it catches you unaware and takes a minute to parse out.

There is an "easy" fix - print "CDK synth succeeded" on stderr and exit 0 as the last step of synth.

[ianchildress]

This documentation needs to be updated to reflect the actual user experience. https://docs.aws.amazon.com/cdk/v2/guide/hello_world.html

[michel-dance]

Allow me to communicate that this "error", has wasted many valuable minutes of my life.

[dustin-engstrom]

This is very confusing. I've read through the thread and here is what I think I've learned. Please correct me if I'm wrong.

The message Please run 'cdk bootstrap' with a recent version of the CDK CLI. in the output is not a warning or error being generated as a result of the command being run currently. Instead it is the content of an assertion that is being added to the stack to detect potential problems in the future. So in the future if an out-of-date version is detected, this message will be shown.

[mukunda-]

Bumbled my way here too 😅. Feeling stupid.

[mat01]

IF YOU ARE COMING HERE AND STILL NOT UNDERSTANDING THIS THREAD (because you scrolled too fast, like me, and missed @chesterm8's write up)

This is NOT an error. YOUR CODE IS FINE.

The cdk synth step creates a number of resources for your app. One of those resources is a check that the deploying tool has the correct version. This is an error that would happen, IF you ran cdk deploy with an out-of-date bootstrap. The AssertDescription would then be the error shown at that point.

This is a "UX" bug because it happens to be the last thing in the diff for the stack after synth, and it catches you unaware and takes a minute to parse out.

There is an "easy" fix - print "CDK synth succeeded" on stderr and exit 0 as the last step of synth.

There is an 'easier' fix - For AWS to stop publishing tools that mislead and confuse, and to do the job that all AWS customers pay them for.

[richstimson]

Correction - cdk diff may not failing. It reports the cdk version check rule under "Other Changes", at the end of its output. The output looks good otherwise. [...] I had interpreted that as failure. Maybe it's not.
Would mind chiming in on this and clarifying the purpose of always seeing this new CheckBootstrapVersion rule going forward? Thanks!

CDK v2 enables the "new-style stack synthesizer" by default (e.g., DefaultStackSynthesizer), which was previously enabled for v1 by setting the @aws-cdk/core:newStyleStackSynthesis feature flag. The DefaultStackSynthesizer uses conventionally named roles and concrete asset storage locations, versus the LegacyStackSynthesizer, which has restricted cross-environment abilities and uses CloudFormation parameters for assets.

With the default synthesizer, the CheckBootstrapVersion rule is added to the Stack's template as a safety check, to verify that the bootstrap stack in the target environment meets the minimum requirements of the current stack. The AssertDescription being shown is the failure message a user would see on deploy if their bootstrap stack was not up-to-date. The inclusion of this element is not a failure, merely a new element for stacks that are being upgraded from the legacy synthesizer. It will show up in the diff until it is deployed, and then will only show up if there's a change, same as any other CloudFormation template element.

Hope that helps! Let me know if you have any follow-ups on that.

I see it's not an error now - but it is really confusing! Hopefully AWS will fix this one day..

[jkellyinsf]

cdk deploy is helpfully printing the error message it would have printed had there actually been an error? That's very, um, proactive?

[pedrettin]

2024 and i just got the "error" and came here to understand how it works LOL

[ovaisoozeer]

May 15th, 2024: the struggle continues... Can we please re-open this, with a view to fixing the error message?

Proposed text update:
...recent version of the CDK CLI. You may ignore this if you are using the correct version and you are synthesizing for the first time

Location:

aws-cdk/packages/aws-cdk-lib/core/lib/stack-synthesizers/stack-synthesizer.ts

Line 332 in 4b6dc8c

assertDescription: `CDK bootstrap stack version ${requiredVersion} required. Please run 'cdk bootstrap' with a recent version of the CDK CLI.`,

[github-actions]

Comments on closed issues and PRs are hard for our team to see.
If you need help, please open a new issue that references this one.

[github-actions]

Comments on closed issues and PRs are hard for our team to see.
If you need help, please open a new issue that references this one.