[9pace]

Follow-up to #2042, which fixed cdk diff for #2036.

Since #1785 (2.1135.0) cdk deploy also describes its change set with IncludePropertyValues. Everything on the deploy path that reads a diff's description misses the changes described in #2042.
So, with --require-approval any-change, 2.1146.0 asks for approval with "There were no differences". toolkit-lib's diff has the same gap for nested stacks.

This PR adds a set of cases to capture this behavior in the paths that were not included in #2042
Every case starts from the following deployed value, built with an intrinsic:

new ssm.StringParameter(this, 'Param', { stringValue: this.toJsonString({ stack: Aws.STACK_NAME, a: '1' }) });

and then adds a key (b: '2') to make it:

new ssm.StringParameter(this, 'Param', { stringValue: this.toJsonString({ stack: Aws.STACK_NAME, a: '1', b: '2' }) });

The last two rows put the same JSON in a container environment variable of an ECS task definition instead. Any change there replaces the task definition, so those rows are about a dropped replacement:

taskDefinition.addContainer('Container', { environment: { CONFIG: this.toJsonString({ stack: Aws.STACK_NAME, a: '1' }) } });

Case	2.1146.0	This PR
cdk deploy --require-approval any-change	hidden	shown
cdk deploy --no-execute --require-approval any-change, then --method=execute-change-set	hidden	shown
toolkit-lib deploy, approval request data	missing	shown
toolkit-lib deploy with execute-change-set, approval request data	missing	shown
toolkit-lib diff, the parameter in a nested stack	hidden	shown
cdk diff --method=change-set, the parameter in a nested stack	shown	shown
cdk deploy --require-approval destructive, task definition	prompts	prompts
cdk deploy --no-rollback, task definition	stops	stops

(2.1146.0 = toolkit-lib 1.44.0)
Each row has an integ test in this PR. The last three rows already work on 2.1146.0, and their tests make sure that stays true:

• cdk diff diffs nested stacks from their templates, not their change sets
• when the dropped change is a replacement, CloudFormation adds a warning to the change set, and the describer then describes it again (fix: change-set diff can miss changes to JSON-typed properties #1785)

In order to fix the behavior defined in these cases:

• Make templates required on ChangeSetDescriber, so no caller can skip the check
• Pass the deployed and the new template everywhere a change set is described
• Describe change sets without property values in the failure diagnoser. It only reads which resources change, and without IncludePropertyValues CloudFormation lists every change, so it needs no templates (reading them would add a GetTemplate call)

small caveat:
Reading the deployed template costs nothing extra for an ordinary deploy, which already read it to decide whether it can skip. With --no-execute, --force, --revert-drift, --method=execute-change-set or cdk validate it costs one GetTemplate per stack.
For execute-change-set the check assumes the change set was created from the current synth, as the approval diff already does. If it was not, the worst case is one extra describe, since everything put back comes from CloudFormation's own description.

Checklist

• This change contains a major version upgrade for a dependency and I confirm all breaking changes are addressed
  • Release notes for the new version:

---

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

[github-actions]

Dependency Review

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

Scanned Files

None

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.10%. Comparing base (8c52d44) to head (6960ecd).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2045   +/-   ##
=======================================
  Coverage   92.10%   92.10%           
=======================================
  Files          82       82           
  Lines       13189    13189           
  Branches     1880     1880           
=======================================
  Hits        12148    12148           
  Misses       1003     1003           
  Partials       38       38           

Flag	Coverage Δ
suite.unit	92.10% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[maintainer-for-aws]

Automated review

A maintainer will still review this — treat the notes below as a starting point.

📌 Commit 6960ecd

This PR threads the deployed and generated templates through every change-set-describer call site so the hide-detection introduced for cdk diff also runs on the deploy-approval path and toolkit-lib's nested-stack diff. It fixes cases where a key added to JSON built with an intrinsic was silently dropped from approval prompts and nested-stack diffs. The core change makes the templates prop on ChangeSetDescriber required so no caller can skip the check, extracts the paging logic into a shared describeAllChangeSetPages helper, and updates the deploy-stack, deployments, toolkit, cfn-api, and diff-helper call sites accordingly; the failure diagnoser is switched to call the helper directly without property values.

No issues found on this change. The surface changes resolve to internal classes rather than the tracked public API, the reordered template read stays inside its existing guard with no new call path, and the diagnoser consumes only resource changes and status, so dropping property values loses nothing it relies on. The behavior is well covered by one integration test per scenario against a dedicated fixture plus matching unit tests.

🔴 0 blocking · 🟡 0 recommended · ⚪ 0 optional

---

Generated automatically. React 👍 or 👎 to tell us whether this review helped, so we can improve these reviews.