Skip to content

docs(cli): document replacements and unwedging in Express Mode - #1970

Draft
sanjanaravikumar-az wants to merge 3 commits into
mainfrom
docs/express-mode-replacements
Draft

sanjanaravikumar-az wants to merge 3 commits into
mainfrom
docs/express-mode-replacements

Conversation

@sanjanaravikumar-az

@sanjanaravikumar-az sanjanaravikumar-az commented Sep 18, 2026

Copy link
Copy Markdown
Contributor

Closes #1739. Documents the Express Mode replacement constraint in the CLI README, next to the existing --no-rollback replacement note.

Replacement-type updates are not supported while rollback is disabled, which Express Mode does by default; CloudFormation classifies this as expected, so it is documented as a constraint rather than a defect. Covers deploying a replacing change with cdk deploy --express --rollback, why that cannot update a stack already in UPDATE_FAILED, why cdk rollback is unavailable for express stacks, and how to unwedge by replaying the last successful configuration with cdk deploy --express --method=direct — including why both flags are needed and how to confirm up front that the replay really is a no-op. Time-bound: CloudFormation is expected to lift the restriction around 2026-11-15.

Every claim is backed by a real deploy. Code fix in #1969; related #1972. Draft pending sign-off from @lvielto, who owns this guidance.

#NNNN here means aws/aws-cdk-cli; note aws/aws-cdk#1931 is an unrelated closed issue.

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

Express Mode has rollback disabled by default, and CloudFormation does not
perform replacement-type updates while rollback is disabled. Document that
constraint next to the existing --no-rollback replacement note: how to deploy a
replacing change (--express --rollback), why --rollback cannot rescue a stack
that is already in UPDATE_FAILED, why cdk rollback is unavailable for express
stacks, and how to unwedge such a stack by replaying the last successful
configuration with --express --method=direct.

Also notes why both flags are required for the replay, how to confirm up front
that the replay really is a no-op, and that CloudFormation is expected to lift
the restriction around 2026-11-15.

Closes #1739
@github-actions

Copy link
Copy Markdown
Contributor

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

@aws-cdk-automation
aws-cdk-automation requested a review from a team September 18, 2026 05:59
…le command

If the failed resource is already at a new revision, restoring the previous
configuration is itself a replacement and CloudFormation refuses it for the same
reason. The page told those users to "deploy with rollback enabled instead",
which is the one operation that provably cannot update a stack already in
UPDATE_FAILED - it answers ValidationError: non-terminal [UPDATE_FAILED] - so a
stranded reader following it literally got a second error and no next step.

Say plainly that there is no known redeploy recovery for that case, and point at
delete/recreate or AWS Support.

This branch had an error being deployed

1 failed (outdated) and 2 active deployments
no-approval 774cab4c Deployed Sep 20, 2026 by sanjanaravikumar-az via prepare #6939
automation 7911d737 Deployed Sep 18, 2026 by sanjanaravikumar-az via Set AutoQueue on PR #1970 #3563
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

effort/medium 1-3 days of effort p1

Projects

None yet

Development

Successfully merging this pull request may close these issues.

cli: bare "Unknown" error and no recovery path when an EXPRESS-mode stack is in UPDATE_FAILED

2 participants