[chenxqdu]

Problem

setup.sh bootstraps with a custom qualifier but no toolkit stack name:

if ! $CDK bootstrap "aws://${ACCOUNT_ID}/${REGION}" --qualifier atxinfra; then

cdk bootstrap writes into the default toolkit stack name CDKToolkit unless --toolkit-stack-name is passed. In any account that already has a normal CDK bootstrap (qualifier hnb659fds) — i.e. almost every account that has ever run cdk deploy — this updates that shared stack in place and switches its qualifier to atxinfra:

• /cdk-bootstrap/hnb659fds/version and the five cdk-hnb659fds-* roles are deleted
• cdk-hnb659fds-assets-<account>-<region> and cdk-hnb659fds-container-assets-<account>-<region> survive as orphans, owned by no stack (the template marks the bucket Retain)
• every other CDK app in that region then fails with ... has not been bootstrapped / missing /cdk-bootstrap/hnb659fds/version

Recovery is awkward, because re-running a plain cdk bootstrap against the same stack fails with cdk-hnb659fds-assets-... already exists — the retained bucket blocks the replacement — which leaves CDKToolkit in UPDATE_ROLLBACK_COMPLETE and forces the default bootstrap to be re-created under a different stack name.

I hit this on a real account: two regions had their default bootstrap converted to atxinfra, one CDKToolkit was left stuck in UPDATE_ROLLBACK_COMPLETE, ~3.6 GB of staging assets were orphaned, and unrelated stacks could no longer be deployed.

teardown.sh already looks for a stack named CDKToolkit-atxinfra first and only falls back to CDKToolkit (checking Qualifier == atxinfra) as a legacy case, so a dedicated toolkit stack looks like the intended layout — setup.sh just never passed the flag.

Change

Bootstrap into CDKToolkit-atxinfra and never touch the shared CDKToolkit. Since existing installs already have their atxinfra resources inside CDKToolkit, the step is guarded so it stays idempotent instead of starting to fail:

1. no /cdk-bootstrap/atxinfra/version → bootstrap into CDKToolkit-atxinfra
2. parameter present → find the stack that owns it (CDKToolkit-atxinfra, then legacy CDKToolkit with Qualifier == atxinfra); skip when it is v21 or newer, otherwise upgrade that stack in place
3. parameter present but no owning stack → warn about leftover resources, then bootstrap into CDKToolkit-atxinfra

Case 2 is what keeps existing users working: pointing a new stack name at an already-bootstrapped qualifier would fail with AlreadyExists on the five roles, the SSM parameter and the ECR repository, and the retained staging bucket would end up managed by two stacks.

The detection key is the SSM parameter because it is tied to the qualifier rather than to a stack name, so it recognises existing installs no matter which stack name they ended up in.

Testing

• bash -n setup.sh
• Ran the new block against a real account with the cdk invocation stubbed out:
  • two regions already bootstrapped with atxinfra inside CDKToolkit → CDK already bootstrapped for qualifier atxinfra (v32 in stack CDKToolkit) — skipping (no hijack, no failure)
  • a region with no atxinfra bootstrap → cdk bootstrap aws://<account>/<region> --qualifier atxinfra --toolkit-stack-name CDKToolkit-atxinfra

Base branch is atx-remote-infra rather than main, since that is where this sample lives (and where #59 / #61 were merged).

Not addressed here

teardown.sh deletes whichever stack holds the atxinfra qualifier, including a legacy CDKToolkit. CloudFormation stacks record their RoleARN permanently, so if anything else in the account was deployed through cdk-atxinfra-cfn-exec-role, deleting that stack leaves those stacks unable to update or delete. That seems worth a similar guard — happy to add it to this PR if you'd prefer it in one change.

🤖 Generated with Claude Code