cli: bootstrap stacks with non-standard name cause diff and import to fail on large templates

[jamestelfer]

Describe the bug

When a synthesized template exceeds the maximum that can be passed inline to the API, the CLI attempts to look up the ToolkitInfo. If the stack name is non-default (e.g. created by a stack set) this lookup will fail, causing an error similar to:

The template for stack "foo" is 108KiB. Templates larger than 50KiB must be uploaded to S3.
Run the following command in order to setup an S3 bucket in this environment, and then re-deploy:

 	$ cdk bootstrap aws://700574780415/us-west-2

Expected Behavior

The ToolkitInfo is trying to create the S3 bucket URL. Normally this would be presented in the manifest as stackTemplateAssetObjectUrl but it is ignored by diff and import.

When using the default synthesizer it should be possible for the CLI to use the correct bucket name without needing to query the bootstrap stack outputs (BucketDomainName).

Current Behavior

The stack name CDKToolkit is queried, which doesn't exist. The command then fails with an error.

Reproduction Steps

1. Bootstrap an environment with a stack name that is not CDKToolkit.
2. Create a template whose size is greater than 50KiB
3. Attempt to diff the template

(note: deploy is fine, as it honours the stackTemplateAssetObjectUrl from the manifest)

Possible Solution

The toolkit information should be accessible regardless of the stack name.

Either:

1. Create another parameter in the bootstrap stack that references the bootstrap stack name, allowing an indirect lookup when the parameter exists. This has a smaller surface area, and could be implemented entirely in ToolkitInfo.lookup. It's similar in spirit to the versionFromSsmParameter lookup that falls back if the parameter doesn't exist.
2. Create parameters for the items that are currently stack outputs, and create a ToolkitInfo instance type that references SSM parameters exclusively instead of using a stack.

Additional Information/Context

The diff will fail to create a changeset but will continue and diff against the template, which is a significant degradation but not an outright failure. It is possible to work around this by specifying the --cdk-toolkit-name.

Imports just fail hard. The workaround for this is to specify the --cdk-toolkit-name on the command line. This is quite tedious when doing this across multiple accounts, but it does allow the process to work.

Since command line parameters can be overridden in the environment, it would be possible to create a parameter (/cdk-toolkit/stack-name or similar) with a known name in the stackset, and use a small script to assign the value of the parameter to the appropriate environment variable for cdk-toolkit-name.

CDK CLI Version

2.150.0

Framework Version

2.150.0

Node.js Version

20.x

OS

Darwin

Language

TypeScript

Language Version

5.1.x

Other information

makeBodyParameterAndUpload calls makeBodyParameter with a fake stack object that has no URL, forcing the failover. This appears to be what triggers the eventual call to ToolkitInfo.lookup() and triggers the failure.

[khushail]

Hi @jamestelfer , Looks like this issue -#29179 is quite similar to the one you have reported. Could you please verify?
Thanks.

[github-actions]

This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.