When a replacement was detected on a stack that is already failed, cdk deploy --express returned replacement-requires-rollback; cdk-toolkit then prompted to redeploy with rollback enabled, and because the confirmation defaults to yes, a non-interactive caller ran it. That deployment cannot succeed:
Change includes a replacement which cannot be deployed with "--no-rollback". Proceeding with deployment with rollback enabled (--force).
ValidationError: This stack is currently in a non-terminal [UPDATE_FAILED] state. To update the stack from this state, please use the disable-rollback parameter with update-stack API. To rollback to the last known good state, use the rollback-stack API
Both remedies in that error are dead ends for an express stack: disable-rollback is the condition CloudFormation refuses replacements under, and RollbackStack is unsupported for stacks last updated with EXPRESS mode. Only replaying the last stable template works, which is what #1970 documents.
#1969 closes this path by throwing ReplacementRequiresUnwedge instead of returning a result, so no prompt is offered and CI cannot auto-run the doomed deployment.
What remains open is the API shape. toolkit-lib consumers now get an error rather than a typed result for this case, where a third member of DeployStackResult — e.g. replacement-needs-unwedge-first — would let programmatic callers branch on it. Neither existing member fits: replacement-requires-rollback means "retry with rollback enabled", and failpaused-need-rollback-first routes to RollbackStack, which #1745 deliberately steered express deployments away from. That is a public addition, so it was kept out of the SEV fix.
CloudFormation is expected to lift the underlying restriction around 2026-11-15, which would make this case rare without changing the API question.
#NNNN here means aws/aws-cdk-cli; note aws/aws-cdk#1931 is an unrelated closed issue.
When a replacement was detected on a stack that is already failed,
cdk deploy --expressreturnedreplacement-requires-rollback;cdk-toolkitthen prompted to redeploy with rollback enabled, and because the confirmation defaults to yes, a non-interactive caller ran it. That deployment cannot succeed:Both remedies in that error are dead ends for an express stack: disable-rollback is the condition CloudFormation refuses replacements under, and
RollbackStackis unsupported for stacks last updated with EXPRESS mode. Only replaying the last stable template works, which is what #1970 documents.#1969 closes this path by throwing
ReplacementRequiresUnwedgeinstead of returning a result, so no prompt is offered and CI cannot auto-run the doomed deployment.What remains open is the API shape. toolkit-lib consumers now get an error rather than a typed result for this case, where a third member of
DeployStackResult— e.g.replacement-needs-unwedge-first— would let programmatic callers branch on it. Neither existing member fits:replacement-requires-rollbackmeans "retry with rollback enabled", andfailpaused-need-rollback-firstroutes toRollbackStack, which #1745 deliberately steered express deployments away from. That is a public addition, so it was kept out of the SEV fix.CloudFormation is expected to lift the underlying restriction around 2026-11-15, which would make this case rare without changing the API question.
#NNNNhere meansaws/aws-cdk-cli; noteaws/aws-cdk#1931is an unrelated closed issue.