feat(cli): warn of non-existent stacks in `cdk destroy` by go-to-k · Pull Request #984 · aws/aws-cdk-cli

go-to-k · 2025-12-10T12:10:02Z

Fixes aws/aws-cdk#32836, aws/aws-cdk#32545, aws/aws-cdk#27179, aws/aws-cdk#22240

Reason for this change

This PR implements the feature that warns users when non-existent stacks are specified in cdk destroy.

It does not display the message Are you sure you want to delete: if there is no matching stack.
Even if the stack does not exist, cdk destroy will not fail, it will just print a warning.

For examples (that have Stacka, StackA, StackX):

Difference from previous PR

The previous PR was reverted in aws/aws-cdk#32839 due to a regression with only nested stage stacks. So this version addresses that regression with comprehensive tests.

Description of changes

The original implementation added warnings for non-existent stacks in cdk destroy, but it failed when applications had only nested stage stacks (no top-level stacks). This happened because the code used allTopLevel: true, which only searched for stacks directly under the App, ignoring stacks within nested Stages.

Fixed the regression by changing suggestStacks method to use DefaultSelection.AllStacks instead of allTopLevel: true, ensuring the warning feature works for all stack configurations (top-level only, nested only, or both). Added regression tests to verify the fix for the nested stage scenario.

  private async suggestStacks(props: {
    selector: StackSelector;
    stacks: StackCollection;
    exclusively?: boolean;
  }) {
    const assembly = await this.assembly();
    const selectorWithoutPatterns: StackSelector = {
-      ...props.selector,
-      allTopLevel: true,
      patterns: [],
    };
    const stacksWithoutPatterns = await assembly.selectStacks(selectorWithoutPatterns, {
      extend: props.exclusively ? ExtendedStackSelection.None : ExtendedStackSelection.Downstream,
-      defaultBehavior: DefaultSelection.OnlySingle,
+      defaultBehavior: DefaultSelection.AllStacks,
    });

Additional Information

When running cdk destroy --all or cdk deploy --all against a configuration with no top-level stacks (nested stages only), the following error occurs.

However, this behavior existed before this PR and is unrelated to the changes made here. Since it is outside the scope of this PR, no fix has been implemented for this behavior.

FYI: I have submitted an issue and a PR about this behavior.

const app = new cdk.App();

new MyStage(app, 'MyStage'); // This has CdkSampleStack

> cdk deploy
Since this app includes more than a single stack, specify which stacks to use (wildcards are supported) or specify `--all`
Stacks: MyStage/CdkSampleStack

> cdk deploy --all
...
No stack found in the main cloud assembly. Use "list" to print manifest

> cdk destroy --all
...
No stack found in the main cloud assembly. Use "list" to print manifest

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

codecov-commenter · 2025-12-10T12:37:46Z

Codecov Report

❌ Patch coverage is 95.55556% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.13%. Comparing base (fff4c93) to head (9c1083c).

Files with missing lines	Patch %	Lines
packages/aws-cdk/lib/cli/cdk-toolkit.ts	95.55%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #984      +/-   ##
==========================================
- Coverage   89.14%   89.13%   -0.02%     
==========================================
  Files          77       77              
  Lines       11539    11528      -11     
  Branches     1605     1602       -3     
==========================================
- Hits        10287    10276      -11     
  Misses       1221     1221              
  Partials       31       31

Flag	Coverage Δ
suite.unit	`89.13% <95.55%> (-0.02%)`	⬇️

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.

The `refactor` command only operates on the stacks that are relevant for the target CDK application. However, it gets all the templates of the deployed stacks before filtering them, which is wasteful. Invert the order, so that the filtering happens before getting the templates. --- By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

…stroy

mrgrain · 2026-06-23T09:30:54Z

@go-to-k I am looking to get this in soon (hence the rebase), but first want to change destroy to use toolkit-lib code internally, so we can avoid duplicate and complicated code.

toolkit-lib: add `force` to DestroyOptions; add W7010/W7011 warnings; move the stack-name suggestion + no-match warning + force-skip into `_destroy`; expose `destroyForAction` as protected so the CLI can keep `deploy` message attribution. aws-cdk: thin destroy delegation with selector -> StackSelector mapping; add `InternalToolkit.destroyFromDeploy`; remove `fromDeploy`/legacy loop; preserve graceful abort on a declined confirmation.

Generated output of routing destroy through toolkit-lib: message-registry.md is regenerated from messages.ts, and the destroy command's __io_snapshots__ reflect the messages now emitted by toolkit-lib. No hand edits.

Move the destroy logic tests to toolkit-lib (including stage/nested-stage regression coverage and the force / suggestion / no-match cases) with new stage fixtures; reduce the CLI tests to delegation/mapping checks; rework the destroy command snapshot test to spy on Deployments.prototype.

The destroy command snapshot test was non-deterministic across color modes: toolkit-lib wraps a leading newline inside a chalk color escape (`\n ✅ ...`), so `withTrimmedWhitespace`'s `.trim()` cannot remove it when colors are on (the string starts with the ANSI escape, not whitespace). The recorder stripped ANSI only after receiving the already-(un)trimmed message, so the leading newline survived with colors on and the snapshot differed between a TTY and CI. Trim in the recorder's `normalize()` after stripping ANSI so the recorded stream is the same regardless of whether colors were enabled, and regenerate the affected snapshots.

go-to-k · 2026-06-24T07:06:12Z

@mrgrain Done. Destroy output now flows through toolkit-lib, so it's coded and consistent with deploy (adds Synthesis time / Destroy time, and the success line is result level). User-facing text is unchanged. (see the diff for the snapshots: packages/aws-cdk/test/commands/_io_snapshots_/destroy/xx.ndjson.)

The destroy confirmation prompt colored the stack names red. Use blue to match the color the CLI used before destroy was routed through toolkit-lib.

go-to-k · 2026-06-24T08:01:35Z

@mrgrain Also restored the confirmation prompt's stack-name color to blue: 4626130

It had turned red because toolkit-lib's destroy used chalk.red, whereas the CLI used chalk.blue before.

Before:

After:

Align cdk destroy with the confirmation-prompt contract from aws#1667: declining now throws AbortError('DestroyAborted', 'Deletion cancelled') and exits non-zero instead of emitting CDK_TOOLKIT_E7010 and exiting 0.

Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

go-to-k · 2026-06-25T05:41:21Z

+    if (stacks.stackCount === 0) {
+      await ioHelper.notify(IO.CDK_TOOLKIT_W7011.msg(
+        `No stacks match the name(s): ${chalk.red((selectStacks.patterns ?? []).join(', '))}`,
+      ));


Note on the exit code: no-match (W7011) exits 0, while a declined confirmation exits 1 (#1667). This is deliberate and keeps the existing behavior. The old selectStacksForDestroy had a // No validation comment and returned an empty selection, so cdk destroy <nonexistent> already exited 0 (deploy throws NoStacksMatched, destroy never did). We keep that contract and add a warning in place of the old empty prompt.

go-to-k · 2026-06-25T05:45:19Z

Merged your PR and fixed conflicts.

Now:

go-to-k · 2026-06-25T05:53:01Z

+    // Trim only after stripping ANSI, so the snapshot is independent of the
+    // active color mode (TTY vs not). toolkit-lib trims its messages, but a
+    // leading newline that is wrapped inside a chalk color escape survives that
+    // trim (the string starts with the escape, not whitespace); once we strip
+    // the ANSI here the newline is re-exposed, so we trim again to keep the
+    // recorded stream deterministic regardless of whether colors were enabled.
+    return out.trim();


Keeps snapshots independent of color mode (TTY vs not): a chalk-wrapped leading newline survives toolkit-lib's own trim, so without this the snapshot differs between color on/off.

go-to-k · 2026-06-25T05:55:25Z

-  /**
-   * Whether the destroy request came from a deploy.
-   */
-  fromDeploy?: boolean;
-


Not breaking: this DestroyOptions is internal to the aws-cdk package (not in its exports), so it isn't user-facing.

go-to-k had a problem deploying to integ-approval December 10, 2025 12:10 — with GitHub Actions Failure

aws-cdk-automation enabled auto-merge December 10, 2025 12:10

aws-cdk-automation requested a review from a team December 10, 2025 12:11

github-actions Bot added the p2 label Dec 10, 2025

auto-merge was automatically disabled December 10, 2025 12:18
Head branch was pushed to by a user without write access

go-to-k had a problem deploying to integ-approval December 10, 2025 12:18 — with GitHub Actions Failure

go-to-k had a problem deploying to integ-approval December 10, 2025 12:28 — with GitHub Actions Failure

go-to-k had a problem deploying to integ-approval December 10, 2025 13:08 — with GitHub Actions Failure

go-to-k had a problem deploying to integ-approval December 10, 2025 13:13 — with GitHub Actions Failure

go-to-k had a problem deploying to integ-approval December 10, 2025 13:17 — with GitHub Actions Failure

go-to-k had a problem deploying to integ-approval December 10, 2025 14:13 — with GitHub Actions Failure

go-to-k had a problem deploying to integ-approval December 10, 2025 14:15 — with GitHub Actions Failure

go-to-k had a problem deploying to integ-approval December 10, 2025 14:16 — with GitHub Actions Failure

go-to-k force-pushed the destroy branch from 7e2eb76 to 5801b2c Compare December 10, 2025 14:18

go-to-k had a problem deploying to integ-approval December 10, 2025 14:18 — with GitHub Actions Failure

go-to-k had a problem deploying to integ-approval December 10, 2025 14:31 — with GitHub Actions Failure

go-to-k mentioned this pull request Dec 10, 2025

fix(cli): deploy and destroy with --all option fail on apps with no top-level stacks #985

Closed

mrgrain force-pushed the destroy branch from c4203ad to 525092d Compare June 22, 2026 08:46

mrgrain requested a deployment to integ-approval June 22, 2026 08:46 — with GitHub Actions Waiting

mrgrain force-pushed the destroy branch from 525092d to 32f465b Compare June 22, 2026 08:49

mrgrain requested a deployment to integ-approval June 22, 2026 08:49 — with GitHub Actions Waiting

mrgrain force-pushed the destroy branch from 32f465b to 2679959 Compare June 22, 2026 09:21

mrgrain requested a deployment to integ-approval June 22, 2026 09:21 — with GitHub Actions Waiting

mrgrain force-pushed the destroy branch from 2679959 to 3d2c68c Compare June 22, 2026 09:23

mrgrain requested a deployment to integ-approval June 22, 2026 09:23 — with GitHub Actions Waiting

Merge branch 'main' of https://github.com/go-to-k/aws-cdk-cli into de…

a1676c3

…stroy

go-to-k requested a deployment to integ-approval June 23, 2026 07:47 — with GitHub Actions Waiting

go-to-k mentioned this pull request Jun 23, 2026

refactor(cli): route cdk destroy through toolkit-lib (review only) go-to-k/aws-cdk-cli#2

Merged

go-to-k added 5 commits June 24, 2026 12:35

chore: regenerate message registry and destroy IoHost snapshots

ec87712

Generated output of routing destroy through toolkit-lib: message-registry.md is regenerated from messages.ts, and the destroy command's __io_snapshots__ reflect the messages now emitted by toolkit-lib. No hand edits.

chore(toolkit-lib): fix picomatch import order (eslint import/order)

102d357

go-to-k requested a deployment to integ-approval June 24, 2026 05:14 — with GitHub Actions Waiting

fix(toolkit-lib): keep destroy confirmation stack names blue

4626130

The destroy confirmation prompt colored the stack names red. Use blue to match the color the CLI used before destroy was routed through toolkit-lib.

go-to-k requested a deployment to integ-approval June 24, 2026 07:58 — with GitHub Actions Waiting

Merge branch 'main' into destroy

d442ab3

Align cdk destroy with the confirmation-prompt contract from aws#1667: declining now throws AbortError('DestroyAborted', 'Deletion cancelled') and exits non-zero instead of emitting CDK_TOOLKIT_E7010 and exiting 0.

go-to-k requested a deployment to integ-approval June 25, 2026 04:55 — with GitHub Actions Waiting

chore: self mutation

9c1083c

Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

aws-cdk-automation requested a deployment to integ-approval June 25, 2026 05:03 — with GitHub Actions Waiting

go-to-k commented Jun 25, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

feat(cli): warn of non-existent stacks in `cdk destroy`#984

feat(cli): warn of non-existent stacks in `cdk destroy`#984
go-to-k wants to merge 10 commits into
aws:mainfrom
go-to-k:destroy

go-to-k commented Dec 10, 2025 •

edited

Loading

Uh oh!

codecov-commenter commented Dec 10, 2025 •

edited

Loading

Uh oh!

mrgrain commented Jun 23, 2026

Uh oh!

go-to-k commented Jun 24, 2026 •

edited

Loading

Uh oh!

go-to-k commented Jun 24, 2026 •

edited

Loading

Uh oh!

go-to-k Jun 25, 2026 •

edited

Loading

Uh oh!

go-to-k commented Jun 25, 2026

Uh oh!

go-to-k Jun 25, 2026

Uh oh!

go-to-k Jun 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Conversation

go-to-k commented Dec 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Reason for this change

Difference from previous PR

Description of changes

Additional Information

Uh oh!

codecov-commenter commented Dec 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

mrgrain commented Jun 23, 2026

Uh oh!

go-to-k commented Jun 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

go-to-k commented Jun 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

go-to-k Jun 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

go-to-k commented Jun 25, 2026

Uh oh!

go-to-k Jun 25, 2026

Choose a reason for hiding this comment

Uh oh!

go-to-k Jun 25, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

go-to-k commented Dec 10, 2025 •

edited

Loading

codecov-commenter commented Dec 10, 2025 •

edited

Loading

go-to-k commented Jun 24, 2026 •

edited

Loading

go-to-k commented Jun 24, 2026 •

edited

Loading

go-to-k Jun 25, 2026 •

edited

Loading