feat(project): tear down the stack on a deploy of an empty project, behind --yes by notgitika · Pull Request #2089 · aws/agentcore-cli

notgitika · 2026-08-24T18:34:39Z

Summary

Deploying a project that declares no resources tore down its stack silently. This makes that outcome explicit, gated, and reported — and fixes the stack-selection gap found in the same review.

A deploy of nothing was a silent delete. The CDK Toolkit reads a template with no resources as an instruction to delete an existing stack of that name, and reports the run as an ordinary successful deploy. #2058 caught it after the fact, by which point the stack was gone.

The first attempt at a guard here was dead code. CDK writes an AWS::CDK::Metadata resource into every stack unless version reporting is disabled, so a project whose spec declares nothing still synthesizes a template with one resource in it — Object.keys(Resources).length === 0 is unreachable through the CLI. Verified against eight real synthesized assemblies. Counting only the resources the project asked for makes the check fire.

Making it fire needs somewhere for that deploy to go. main supports this: empty the project, deploy, and the stack is destroyed. The refactor dropped it, so refusing outright would trade a silent delete for a regression. Instead the deploy routes to an explicit toolkit.destroy(), gated on --yes:

$ agentcore project deploy
Project 'orders' declares no resources to deploy, so deploying to target 'default'
would delete stack 'AgentCore-orders-default' and every resource in it.
Re-run with --yes to confirm, or restore the resources the project should have.

$ agentcore project deploy --yes
Removing stack AgentCore-orders-default
Removed project 'orders' from target 'default'

Three states are distinguished, all before anything is destroyed:

Project declares	Stack exists	`--yes`	Outcome
resources	—	—	deploy
nothing	yes	no	refuse, naming the stack that would be deleted
nothing	yes	yes	destroy, reported as Removed
nothing	no	—	refuse: add a resource, e.g. `project add runtime`

Destroying explicitly rather than deploying the empty template is what makes the outcome reportable: destroy fails loudly when the stack cannot be removed, where a deploy of an empty template succeeds either way. The empty-outputs guard in performCdkOperation stays as the backstop for reaching that state some other way.

Detection reads the synthesized template rather than counting spec collections the way main does, so a resource type added to the spec later is covered without anyone remembering to extend a list.

Stack selection also matched on the target-name tag alone, never on the account and region the artifact was synthesized for. Those derive from the same target today and so cannot disagree, but nothing enforced it, and the Toolkit deploys where the artifact's environment points rather than where the tag says. Both fields were being stripped on read, since the manifest schema declared neither.

stackArtifactIdForTarget becomes stackArtifactForTarget, returning the template path and the deployed stack name alongside the id. The stack name is derived as properties.stackName ?? artifactId, which is CDK's own derivation — so the name handed to CloudFormation is the one the Toolkit would have used.

Testing

bun test src/ — 1985 pass, 0 fail against these files. Unit coverage for each state in the table, for the metadata-only template that made the original guard dead, and for the ordering that makes the guards meaningful: every check runs before the Toolkit is called, so a bad target or an unconfirmed teardown fails without touching AWS. probeStack is covered for a present stack, a stack mid-rollback, an absent stack, an empty response, and a permissions failure — the last matters because reporting "no stack" on an AccessDeniedException would turn a confirmed teardown into an unexplained "add a resource" error.

Notes

main deletes orphaned harnesses and config bundles before destroying the stack, because it creates some of them imperatively. This branch creates everything through CloudFormation, so the stack deletion covers them; nothing is intentionally left behind, but flagging it in case a later imperative resource needs the same treatment.

codecov-commenter · 2026-08-24T20:03:11Z

Codecov Report

❌ Patch coverage is 99.53704% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 97.24%. Comparing base (fadad5a) to head (552717b).

Files with missing lines	Patch %	Lines
src/core/factories.tsx	66.66%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##           refactor    #2089      +/-   ##
============================================
+ Coverage     97.19%   97.24%   +0.04%     
============================================
  Files           471      471              
  Lines         28731    28911     +180     
============================================
+ Hits          27925    28114     +189     
+ Misses          806      797       -9

☔ 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.

agentcore-devx-automation · 2026-08-25T20:02:11Z

Claude Security Review: no high-confidence findings. (run)

nborges-aws · 2026-08-25T20:19:17Z

+): void {
+  // An artifact with no environment is environment-agnostic: it deploys into
+  // whatever the credentials resolve to, which the account preflight checked.
+  if (environment === undefined) return;


For my own understanding: wouldn't CDK write unknown-account and unknown-region if env-agnostic? The comment on L9 says thats the case, but this comment says no env = env-agnostic.

Hweinstock · 2026-08-25T20:22:54Z

Rejects a synthesized stack that declares no resources.

I kind of think we want the opposite. If I clear all of my resources, then deploy, I'd expect that to delete the stack. Without this functionality, how do I destroy the AWS resources I've created with the CLI?

I could see an alternative where we offer an explicit destroy, but that feels overly complex.

agentcore-devx-automation · 2026-08-27T20:06:01Z

Claude Security Review: no high-confidence findings. (run)

agentcore-devx-automation · 2026-08-27T20:27:44Z

Claude Security Review: no high-confidence findings. (run)

Hweinstock

mostly nits or questions, but two things I'm hesitant about.

the cloudformation client deviates from the existing aws client pattern and isn't injected. This means we don't cache it and make use of persistent connections, and can't leverage the existing fixtures for testing.
we have a lot of testing at a lot of different levels, which is great, but I'm wondering if we can rely on handlers for most of this. I remember having a discussion with alex about how these tests can become friction when making changes, rather than giving us confidence we didn't break anything.

Hweinstock · 2026-08-27T20:45:05Z

+  .passthrough();
+
+/** The synthesized stack a deploy selected, and where its template lives. */
+export interface StackArtifact {


nit: should this be a type since its not expecting extensions or implementations?

yep, changing to type

Hweinstock · 2026-08-27T20:49:31Z

+  };
+}
+
+async function promptForTeardown(


very simple! I like the injection + how we re-use UserCancellationError too.

Hweinstock · 2026-08-27T20:56:11Z

+   */
+  confirmTeardown: boolean;
+  /** Requests approval after the backend discovers that this deploy is a teardown. */
+  requestTeardownConfirmation?: TeardownConfirmationHandler;


Would this be simpler if we inject a teardown confirmer that returns true if --y was passed, and otherwise prompts?

Hweinstock · 2026-08-27T20:57:40Z

+export type TeardownConfirmationRequest = {
+  projectName: string;
+  targetName: string;
+  stackName: string;


is this leaking CDK specifics into this interface? If we do support non-IaC or terraform, what would we fill here?

you are right good catch let me keep it generic here

Hweinstock · 2026-08-27T20:58:50Z


+  // The backend decides whether a deploy of nothing is a teardown; the manager's
+  // job is only to carry the user's confirmation through to it.
+  test("passes the teardown confirmation through to the backend", async () => {


is this property already covered by the handler tests where we inject the fake backend? If it didn't route, those tests wouldn't work.

yes it is let me remove this test

Hweinstock · 2026-08-27T21:03:53Z

+const describeStack: StackReader = async (stackName, region, credentials) => {
+  const { CloudFormationClient, DescribeStacksCommand } =
+    await import("@aws-sdk/client-cloudformation");
+  const client = new CloudFormationClient({ credentials, region });


I think we'll want to inject this client to follow the existing DI pattern.

ahh good point, I’ll follow the existing injected and cached AWS client pattern here

nborges-aws

LGTM

Two review findings from #2058, both cases of deploy trusting something it had not checked. A synthesized template with no resources makes the CDK Toolkit *delete* an existing stack of that name and return as though it deployed. #2058 caught that after the fact, by which point the stack was already gone. Check the resource count before handing the assembly to the Toolkit instead. Stack selection matched on the target-name tag alone, never on the account and region the artifact was synthesized for. Those derive from the same target today and so cannot disagree, but nothing enforced it, and the Toolkit deploys where the artifact's environment points rather than where the tag says. Both fields were also being stripped on read, since the manifest schema declared neither. stackArtifactIdForTarget becomes stackArtifactForTarget, returning the template path alongside the id so the resource check needs no second read of the manifest.

…ith --yes The resource check added in the previous commit never fired. CDK writes an AWS::CDK::Metadata resource into every stack unless version reporting is disabled, so a project whose spec declares nothing still synthesizes a template with one resource in it: Object.keys(Resources).length === 0 is unreachable through the CLI. Verified against eight synthesized assemblies. Count only the resources the project asked for, and the check becomes real. Making it real needs somewhere for that deploy to go. main handles it -- an empty project plus deploy destroys the stack -- and refactor dropped that along the way, so refusing outright would trade a silent delete for a regression. Route it to an explicit toolkit.destroy() instead, gated on --yes, and report it as "Removed" rather than "Deployed" since the stack no longer exists. Destroying explicitly rather than deploying the empty template is what makes the outcome reportable: destroy fails loudly when the stack cannot be removed, where a deploy of an empty template succeeds either way. The existing guard in performCdkOperation stays as the backstop for reaching that state some other way. Two states are distinguished before anything is destroyed, both by probing CloudFormation for the stack: nothing to deploy and no stack to remove is a project that needs a resource added, not a teardown. Detection reads the synthesized template rather than counting spec collections the way main does, so a resource type added to the spec later is covered without anyone remembering to extend a list. Also corrects the comment nico flagged: an artifact with no environment is not the env-agnostic case -- CDK spells that out as aws://unknown-account/unknown-region -- it is a manifest field the cloud assembly schema leaves optional.

agentcore-devx-automation · 2026-08-27T22:00:08Z

Claude Security Review: no high-confidence findings. (run)

Hweinstock

lgtm, thanks for addressing earlier comments.

Hweinstock · 2026-08-27T22:21:40Z

+) => Promise<boolean>;
+
+/** Shares CloudFormation connections for calls using the same credentials and region. */
+export function createCloudFormationStackReader(


ah, for my own understanding, is this to handle deploying to multiple targets?

a single deploy is scoped to one target/region, so this isn't a multi-target thing.

it's just memoizing one CloudFormationClient per (credentials, region) so the CloudFormation reads we make (the CDKToolkit bootstrap probe and the empty-project stack probe) reuse a client instead of building a new one each time. Keying by (credentials, region) means it'd also stay correct if a caller ever spanned regions/targets

github-actions Bot added the size/xl PR size: XL label Aug 24, 2026

notgitika had a problem deploying to e2e-testing August 24, 2026 18:35 — with GitHub Actions Failure

notgitika mentioned this pull request Aug 24, 2026

feat(project): implement safe CDK deployment #2058

Merged

github-actions Bot added agentcore-harness-reviewing AgentCore Harness review in progress size/xl PR size: XL and removed agentcore-harness-reviewing AgentCore Harness review in progress size/xl PR size: XL labels Aug 24, 2026

Base automatically changed from feat/project-deploy-implementation to refactor August 24, 2026 19:39

notgitika force-pushed the feat/project-deploy-credentials branch from a1b6cbf to c255cdd Compare August 24, 2026 19:50

notgitika marked this pull request as draft August 24, 2026 19:50

notgitika changed the title ~~feat(project): create credential providers before synthesizing a deploy~~ fix(project): stop deploy silently dropping credentials, deleting stacks, and trusting a tag Aug 24, 2026

notgitika changed the title ~~fix(project): stop deploy silently dropping credentials, deleting stacks, and trusting a tag~~ fix(project): tighten agentcore project deploy command Aug 24, 2026

notgitika force-pushed the feat/project-deploy-credentials branch from 1a13ff1 to dfb7780 Compare August 24, 2026 20:38

notgitika changed the title ~~fix(project): tighten agentcore project deploy command~~ fix(project): stop deploy deleting stacks and trusting a tag Aug 24, 2026

notgitika mentioned this pull request Aug 24, 2026

project deploy cannot create payment credential providers; support Quick Create connectors first #2095

Open

notgitika changed the title ~~fix(project): stop deploy deleting stacks and trusting a tag~~ fix(project): deploy credentials through CloudFormation, and stop deleting stacks Aug 24, 2026

notgitika mentioned this pull request Aug 24, 2026

credential provider follow-ups: name collisions, vendor change, and an untested secret-delete risk #2093

Open

notgitika force-pushed the feat/project-deploy-credentials branch from 378208a to f20c060 Compare August 25, 2026 19:59

notgitika changed the title ~~fix(project): deploy credentials through CloudFormation, and stop deleting stacks~~ fix(project): check the template before letting the Toolkit deploy it Aug 25, 2026

github-actions Bot added size/m PR size: M and removed size/xl PR size: XL size/m PR size: M labels Aug 25, 2026

agentcore-devx-automation Bot added the claude-security-reviewing Claude Code /security-review in progress label Aug 25, 2026

notgitika marked this pull request as ready for review August 25, 2026 20:01

agentcore-devx-automation Bot removed the claude-security-reviewing Claude Code /security-review in progress label Aug 25, 2026

nborges-aws reviewed Aug 25, 2026

View reviewed changes

notgitika force-pushed the feat/project-deploy-credentials branch from 1763df3 to 6263477 Compare August 27, 2026 20:03

github-actions Bot added size/l PR size: L and removed size/l PR size: L labels Aug 27, 2026

agentcore-devx-automation Bot added the claude-security-reviewing Claude Code /security-review in progress label Aug 27, 2026

agentcore-devx-automation Bot removed the claude-security-reviewing Claude Code /security-review in progress label Aug 27, 2026

github-actions Bot added size/xl PR size: XL and removed size/l PR size: L labels Aug 27, 2026

agentcore-devx-automation Bot added the claude-security-reviewing Claude Code /security-review in progress label Aug 27, 2026

agentcore-devx-automation Bot removed the claude-security-reviewing Claude Code /security-review in progress label Aug 27, 2026

notgitika requested review from Hweinstock and nborges-aws August 27, 2026 21:07

Hweinstock reviewed Aug 27, 2026

View reviewed changes

nborges-aws previously approved these changes Aug 27, 2026

View reviewed changes

notgitika added 5 commits August 27, 2026 17:55

refactor(project): remove redundant stack environment check

975a25c

feat(project): prompt before tearing down empty deployments

11db5bb

refactor(project): address deploy review feedback

552717b

notgitika dismissed nborges-aws’s stale review via 552717b August 27, 2026 21:57

notgitika force-pushed the feat/project-deploy-credentials branch from df52c92 to 552717b Compare August 27, 2026 21:57

github-actions Bot added size/xl PR size: XL and removed size/xl PR size: XL labels Aug 27, 2026

agentcore-devx-automation Bot added the claude-security-reviewing Claude Code /security-review in progress label Aug 27, 2026

agentcore-devx-automation Bot removed the claude-security-reviewing Claude Code /security-review in progress label Aug 27, 2026

Hweinstock approved these changes Aug 27, 2026

View reviewed changes

notgitika merged commit 059e1a5 into refactor Aug 28, 2026
22 checks passed

notgitika deleted the feat/project-deploy-credentials branch August 28, 2026 03:26

Uh oh!

Conversation

notgitika commented Aug 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Testing

Notes

Uh oh!

codecov-commenter commented Aug 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

agentcore-devx-automation Bot commented Aug 25, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Hweinstock commented Aug 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

agentcore-devx-automation Bot commented Aug 27, 2026

Uh oh!

agentcore-devx-automation Bot commented Aug 27, 2026

Uh oh!

Hweinstock left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nborges-aws left a comment

Choose a reason for hiding this comment

Uh oh!

agentcore-devx-automation Bot commented Aug 27, 2026

Uh oh!

Hweinstock left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

notgitika commented Aug 24, 2026 •

edited

Loading

codecov-commenter commented Aug 24, 2026 •

edited

Loading

Hweinstock commented Aug 25, 2026 •

edited

Loading