terraform-aws-modules/terraform-aws-alb examples/complete-alb (tag v9.9.0), its flagship application-load-balancer example
Source: https://github.com/terraform-aws-modules/terraform-aws-alb.git at v9.9.0.
Set: core. Lane: terraform-popular.
Why it is in the core set: a most-downloaded terraform-aws-modules example, pinned by tag; the shape most people deploy
Not clear yet.
| Stage | Verdict | Detail |
|---|---|---|
| Cold deploy | pass | 80 resources, once for real (floci fixes #58, #61, #62) |
| Migrate | pass | 51 of 80 stamped, 1 recorded, 0 failed, 28 skipped |
| Replan from nothing | pass | empty live-plan with no state file; 0 Error diagnostics; the two record-rung aws_route53_record.validation identities verified by value against route53 list-resource-record-sets |
| No-op apply | pass | genuine no-op (0 added, 0 changed, 0 destroyed); 50 tofu-estate-tagged objects before, 50 after |
| Drift and reconverge | pass | one object tampered (the ALB’s Example tag), plan proposed fixing exactly module.alb.aws_lb.this[0], apply changed 1 and the Example tag reconverged |
| Rename | pass | moved block: aws_instance.this renamed with zero churn (0 add, 1 change, 0 destroy), marker rewritten in place; live-mv: aws_instance.other renamed with zero churn, marker rewritten in place; stock oracle over the same two-object rename on cold_deploy’s own state (positioned right after stage 1, before migrate ever touches these shared objects) also shows zero churn (0 add, 0 change, 0 destroy); both live ids unchanged, read via the AWS CLI |
| Remove a block | pass | choudoufu: deleting aws_instance.other_renamed’s block (and its one target-group-attachment reference) proposed exactly 2 destroys (0 add, 0 change, 2 destroy), matching the stock oracle and applied cleanly; the instance is confirmed terminated via the AWS CLI, not through choudoufu’s own report; the next plan proposes no resource action; stock oracle on cold_deploy’s own state (D-REMOVE-ORACLE) also proposes exactly 2 destroys for the same two objects |
| Change count (planned) | not run | |
| Replace with create_before_destroy | not run | |
| Crash between create and destroy (planned) | not run | |
| Teardown (planned) | not run | |
| Plan, review, apply (planned) | not run | |
| Greenfield apply | pass | 80 resources from nothing, matching stock’s own cold-deploy count; the ALB’s markers verified via the AWS CLI; 80 records in the local record store including untaggable types; replan empty; a representative EC2 instance’s own shape (type/ami) matches stock’s cold deploy, via the AWS CLI on both endpoints, marker tags never compared; 50 objects carry the estate tag |
| Strict profile (planned) | not run |
Last run at commit df0cc6a075 on 2026-08-25T17:32:35Z, exit code 0.
Landed 2c654caa23 (2026-08-18), 80 resources. cold_deploy and migrate genuinely pass (48 of 80 eligible, 44 stamped - 4 failed to stamp on a real, filed floci gap, lex00/floci#65: ELBv2 DescribeListeners/DescribeRules drop AuthenticateCognitoConfig/AuthenticateOidcConfig entirely, so those 4 listener-rule sites can’t round-trip; 32 skipped - 28 untaggable by design, 4 unadmitted). test_plan blocked by #305 (3 sites) and a NEW one, filed as #309: aws_cognito_user_pool_client is unadmitted despite a parent-scoped ListUserPoolClients existing (via the already-admitted aws_cognito_user_pool parent) - a concrete lead for a fix, not attempted here. Three real floci gaps found, fixed, and merged to floci main (9ff82512, already reconciled into that history - not a pending PR): #58 (ACM wildcard-SAN DNS validation record kept a literal “.” in its name), #61 (S3 log-delivery-write canned ACL rejected), #62 (EC2 instance-type catalog missing t3.nano). One floci gap found and left open as real feature work: #63 (Cognito CreateUserPoolDomain entirely unimplemented), worked around with a documented delta. Deliberately did NOT re-pin live/floci-image here - bumping the pin without a matching floci-capabilities.json regen breaks TestFlociServiceCapability/TestFlociTypeCapability, and several other crossings tonight need the same regen, so this was left for a single centralized reconciliation rather than each crossing re-pinning independently and colliding. Verified twice via FLOCI_IMAGE override pointed at the real published digest (sha256:217f859688b5…) instead. Follow-up pass 2026-08-18 (#313 cross-check, d7e44cbfda/29095a37b7): the committed run.sh still asserted pre-#305 counts (48/80 eligible, 44 stamped, 4 unadmitted-type including the default_ trio) and failed before ever reaching stage 3; updated to the real current numbers - 51 eligible, 47 stamped, #309 (aws_cognito_user_pool_client) now the SOLE unadmitted-type/test_plan blocker, #305’s trio fully resolved - re-verified against real floci twice plus a BREAK=1 negative control. #313’s diagnostic does not appear anywhere in the output despite this estate also declaring data.aws_availability_zones feeding module.vpc; confirmed not the same wall. Commented on #313 and #309. RE-VERIFIED 2026-08-21 (this session, worktree live/reverify-limitations, floci pinned at the current e61a987/d65baf42 image): stages 1-2 unchanged byte-for-byte (80 cold-deployed; dry run 51/80 eligible, 41 VERIFIED + 10 DRIFTED, 29 skipped; -approve 47 stamped, 1 recorded, 4 failed on the still-open lex00/floci#65, 28 skipped). Stage 3’s underlying wall is UNCHANGED in substance - still exactly one site, aws_cognito_user_pool_client.this, still #309, still label 3 - but its diagnostic TEXT has moved: commit 5444949ceb (2026-08-19 22:57, “widen the markerless veto to a mixed primary identifier”, #309’s own chain) added aws_cognito_user_pool_client to identity.MarkerlessTypes, which reclassifies the refusal from RuleUnadmittedType (“Resource type is outside the live-markers subset”) to the more specific RuleMarkerlessType (“Resource type has nowhere to write an ownership marker”) - same site, same practical block, different rule ID and error string. That commit landed after run.sh (c926095b49) was last edited, so run.sh’s own hard-coded stage-3 assertion (grep for the old RuleUnadmittedType text) no longer matches and the script now hard-fails at its own assertion check (“expected 1 unadmitted-type sites (#309), got 0”) before ever reaching its SUMMARY block, rather than reaching a clean itemized stage-3 refusal. Stage 2’s live-import output still labels the same site UNADMITTED_TYPE, so stage 2 and stage 3 now use inconsistent labels for the identical site - a real, if narrow, drift worth fixing when someone next touches this script (update the grep target to RuleMarkerlessType’s text), not attempted here per this session’s verification-only scope. Separately confirmed: run.sh’s header (lines 92-131) still does not state the maintainer’s 2026-08-21 “Label 3, OpenTofu was never asked this question, stop here” ruling in as many words - HANDOFF.md’s “What to do next” item 2 documentation task is still open. #337 (composite-identity route, 18 types) is confirmed NOT implicated - the responsible commit is on the #309 chain itself, predating #337. #331/#340/#343/#344 did not touch this estate.
Reproduce it#
go run ./tools/gauntlet run corpus-alb-completeNeeds Docker (the emulator is pulled at the pinned digest), the AWS CLI, and a
stock terraform or tofu binary on PATH for the cold deploy. The script is
live/e2e/corpus-alb-complete/run.sh; BREAK=1 corrupts its assertions to show they are load-bearing.