Forge destroy leaves OpenTofu AWS/IAM resources (EntityAlreadyExists on redeploy)

[jgruberf5]

Stack-delete tears down K8s but not AWS-provider modules. Detail: .agent/ROADMAP.md §5. followup_forge_destroy_leaves_iam_resources

---

_{Migrated from sp-prod-field/bnk-forge #182 (opened 2026-05-27; original labels: enhancement). That repository is archived and read-only.
Bare #NNN references in the text above refer to issues and PRs in the original repository, not to numbering here.}

[jgruberf5]

Triaged while working through the severity:high queue. I did not open a PR — this is not specified enough to fix safely, and I could not reproduce the described behaviour from the code.

What the issue points at is not available here

The body defers to .agent/ROADMAP.md §5. That file is not in this repository; docs/ROADMAP.md has the entry, but it is the same one line with no additional detail:

⚪ Planned Forge-destroy leaves OpenTofu AWS/IAM resources → EntityAlreadyExists — followup_forge_destroy_leaves_iam_resources

The referenced followup_* memo is not in the repo either.

What I checked, and what it rules out

The stated symptom is "Stack-delete tears down K8s but not AWS-provider modules." That is not what the destroy path does. StackDeploymentService.destroy_stack selects modules purely by status:

elif module.status in [ModuleStatus.APPLIED, ModuleStatus.APPLY_FAILED, ModuleStatus.DESTROY_FAILED]:
    # CP-009: Has or may have infrastructure to destroy
    modules_to_destroy.append(module)

There is no provider, engine, or module-type conditional anywhere in that selection — an AWS-provider module in applied is queued for destroy exactly like a K8s one. So whatever causes the leak, it is not "stack-delete skips AWS modules".

That leaves more plausible candidates, none of which I can distinguish without an AWS account and a reproduction:

1. the IAM resources are created outside OpenTofu state (a provisioner or script), so tofu destroy was never going to remove them;
2. tofu destroy partially fails on those resources and the module is still driven to a terminal destroyed state, so the failure is not surfaced;
3. the resources belong to a module that was already deleted directly (the modules_to_delete branch above deletes rows for modules believed to have no infrastructure — if that belief is ever wrong, resources are orphaned with no destroy attempt at all).

Candidate 3 is the one I would look at first, and it is testable without AWS.

What would make this actionable

• the actual EntityAlreadyExists error text and which IAM entity it names;
• which module/blueprint created it (aws_iam_role? IRSA? the EKS module?);
• whether tofu destroy reported success for that module, and the task log if not;
• ideally tofu state list for that workspace before destroy, showing whether the IAM resource was ever tracked.

Fixing cloud teardown by guesswork has real blast radius — the same class of failure as #82, where a destroy silently targeted the wrong cluster — so I would rather leave this open than ship a speculative change to it. Happy to pick it up once there is a reproduction, or to investigate candidate 3 specifically if that is useful.

_{No PR opened. All other severity:critical/severity:high bugs from this pass are linked to their PRs.}

[jgruberf5]

Fixed in #151, squash-merged to staging as 29975f37.

Closing manually — the auto-close Action does not fire on these PRs because the PR template's Fixes / Implements: #N format is not a shape its parser accepts.