AWS pre-flight sweep — run it for EVERY fixture, unconditionally:
bash tests/integration/_lib/aws-orphan-sweep.sh <test-name>; rc=$?
Do NOT first decide whether the fixture is AWS-resource-owning. That
decision has silently excluded a resource-owning fixture twice
(*-from-cfn-stack missed three, and the widened *-from-cfn* still missed
local-invoke-assume-role, which deploys a stack containing an IAM role),
and the script now makes it internally, from one predicate, against the
fixture's own verify.sh. A fixture that owns nothing makes no AWS call and
exits 0. aws-orphan-sweep.sh --list-owners prints the derived set if you
want to see it.
Also confirm the deploy toolchain is present — the sweep checks that
AWS is reachable, not that the fixture can deploy, and this was dropped
when the recipe became a script:
which cdk
Only needed when the sweep reported the fixture as AWS-owning (rc 0 with a
fixture= line rather than the "owns no real AWS resource" line).
Gate on the exit code. Do not read the output and judge. That is the
whole point of go-to-k/cdk-local#601 — the previous recipe was prose whose
error branches nobody executed, and it carried four instances of one defect
class in a single PR (a bare stack name that could never match, a /cdkl
scope that listed every lane, a filter that degraded to contains(Name,'-')
over the whole ACCOUNT, and two stack scans with no guard at all, where a
wrong cwd produced a false clean on the PRIMARY resource):
| rc | meaning | what to do |
|---|
| 0 | clean | proceed to step 5 |
| 1 | usage / internal error | STOP. Nothing was concluded. Read the FATAL line. |
| 2 | orphan found | STOP. Remediate — see below. |
| 3 | indeterminate | STOP. A query could not be performed (no credentials, aws missing, an unrecognized error). This is NOT clean. |
| 4 | report-only | STOP and check by hand. An UNATTRIBUTABLE resource matched — see below. |
Anything non-zero means do NOT proceed and do NOT set the marker in step 9.
The decisions the script encodes (its file header states each with its
reason, and aws-orphan-sweep.test.sh executes every failure path rather
than grepping for it): the lane suffix is resolved ONCE from a
BASH_SOURCE-derived path, so a wrong cwd cannot change any answer; stack
names, SSM paths, the CloudFormation export and the un-suffixed froms3
bucket are all DERIVED from the fixture, so a caller cannot forget one;
describe-stacks --stack-name is used rather than a status filter (which
hid 16 of 23 statuses, DELETE_IN_PROGRESS — an interrupted cdk destroy,
this sweep's own scenario — among them); exit 0 from describe-stacks is
the ORPHAN case; no query silences stderr; and the SSM / export filters
carry BOTH the cdkl anchor and this lane's suffix, with contains rather
than ends_with because local-invoke-from-cfn-stack-large-stack creates
~105 parameters shaped /cdkl-ls-<suffix>/p000.
On rc=2, the script PRINTS the remediation plan. Run what it printed.
It names the SUFFIXED stacks (a base name matches nothing and reports
success), uses aws cloudformation delete-stack and never cdk destroy
(which needs --app context this cwd does not provide and, repaired by
hand, exits 0 SILENTLY on a name the app never synthesized — this defect
class arriving through the remediation), and tells you to re-run the sweep
afterwards, since no delete command reports "I matched nothing".
First, confirm it is not a LIVE peer. A name under this lane's suffix
can also belong to a second run of the same fixture in the SAME worktree.
Check for a running verify.sh before deleting anything. Cross-worktree
lanes can no longer collide, which is the point of the suffix.
On rc=4 the match is a froms3 bucket, whose name carries no lane hash
at all (account + region + timestamp), so it may be a concurrently running
peer's LIVE bucket. It is reported, never attributed — same live-peer check,
and delete only what you have confirmed is yours.
