terraform-aws-modules/terraform-aws-rds examples/complete-postgres (tag v7.2.1)
Source: https://github.com/terraform-aws-modules/terraform-aws-rds.git at v7.2.1.
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 | 39 resources, once for real |
| Migrate | pass | 26 of 39 stamped |
| Replan from nothing | pass | genuinely empty replan (No changes. Your infrastructure matches the configuration.) with no local state file. lex00/floci#120’s round-trip gap, this estate’s last recorded wall, is CONFIRMED FIXED: round 8 (PR #128/ff815779, ghcr.io/lex00/floci:main-20260824d sha256:25fc9687, #124’s RDS colliding-port isolation) closed the last of its eight fields for this estate - module.db_default’s own port (module.db and module.db_default both declare port=5432, a genuine collision; module.db_default is the second-created instance and gets its own distinct loopback bind address with the declared port honored). The other seven fields (backup_window, monitoring_interval, monitoring_role_arn, performance_insights_retention_period, engine_lifecycle_support, enabled_cloudwatch_logs_exports, max_allocated_storage) and the parameter block’s apply_method were already fixed by earlier rounds (round 5 and round 6’s own #120 passes) that this estate had not been re-crossed since - the artifact’s recorded ‘3 in-place updates’ detail was stale before this round’s own fix even landed. Confirmed three independent ways, not merely inferred from the empty plan: a direct describe-db-parameters –source user probe of the live parameter group (autovacuum=1, client_encoding=utf8, matching config exactly, no tofu in the loop), a direct describe-db-instances probe of the second instance’s own Endpoint.Port (5432, the declared port), and all eight attribute names individually confirmed absent from choudoufu’s plan. INTENTIUS/choudoufu#393 (skip_final_snapshot’s phantom true->false update) remains fixed, confirmed absent. Stock’s own replan against its own never-deleted state file still shows tag noise plus the two parameter blocks; ruled out as a live discrepancy by the same direct API probe (informational only, not this stage’s oracle - HANDOFF row 3, a property of that one state file’s own apply-time fidelity). |
| No-op apply | pass | genuine no-op: 26 objects before, 26 after, no state file, primary DB instance marker unmoved |
| Drift and reconverge | pass | one object tampered (primary DB instance’s Example tag), plan proposed fixing exactly one object, apply changed 1 and reconverged the tag |
| Rename | pass | moved block: module.security_group renamed with zero churn (0 add, 1 change, 0 destroy), marker rewritten in place; live-mv: module.db_default’s db instance renamed with zero churn, marker rewritten in place; stock oracle over the same two-object rename on cold_deploy’s own state 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 module.db_default_renamed’s block proposed exactly two destroys (the db instance and its own local random_id.snapshot_identifier, no cloud representation - issue #340), applied cleanly, the db instance is genuinely gone from the live account (read via the AWS CLI, not choudoufu’s own report), and the next plan proposes no resource action; stock oracle on the same renamed oracle tree also proposes exactly the same two destroys; the target was chosen (see header) because its own nested module.db_instance call has no untaggable AWS-side sibling under this estate’s create_db_option_group=false/create_db_parameter_group=false, unlike the shapes that surfaced issue #410 for corpus-s3-bucket-complete and corpus-overture-tiles |
| 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 | 39 resources from nothing (same DELTA reduction cold_deploy itself needs - two emulator gaps, floci-io/floci#51 and lex00/floci#52), primary DB instance and security group markers verified via the AWS CLI, 39 records in the local record store (#364 A2), replan empty, stock oracle in its own namespace matches structurally (DB engine/version/class/storage/port, security-group rule count) |
| Strict profile (planned) | not run |
Last run at commit e99a19e074 on 2026-08-25T17:57:14Z, exit code 0.
RE-CROSSED FOR REAL 2026-08-21 at dbc5ebf575 (GitHub issue #346’s fix), twice, the second time with an instrumented copy of the script that dumps live-plan’s raw output so the diagnostics could be quoted rather than inferred. STAGES UNCHANGED at 2 of 5, and #346’s fix DOES NOT REACH THIS ESTATE - which refutes the ‘four estates share one wall’ framing #346 was filed under. Stage 1: ‘Apply complete! Resources: 39 added, 0 changed, 0 destroyed’. Stage 2: ‘26 of 39 eligible (20 VERIFIED + 6 DRIFTED); 13 skipped (UNTAGGABLE by provider schema)’; ‘26 stamped, 1 recorded (random_id.snapshot_identifier), 0 failed, 12 skipped’; the primary aws_db_instance’s tofu-address/tofu-estate asserted by exact value through the AWS CLI. Stage 3 fails on exactly the same 2 diagnostics as before, same lines, same text: ‘Module output not supported in static context’ on main.tf:198 (cidr_blocks = module.vpc.vpc_cidr_block, inside the module CALL argument ingress_with_cidr_blocks) and ‘Unable to compute static value’ on the security-group module’s own main.tf:197 (cidr_blocks = compact(split(’,’, lookup(var.ingress_with_cidr_blocks[count.index], ‘cidr_blocks’, join(’,’, var.ingress_cidr_blocks))))). Why the fix misses it, measured rather than guessed: this estate’s shape has no each.value anywhere. It is COUNT-indexed, and the module output is consumed as a module-CALL argument, which travels tolerantVariables/rebuildConstructor/moduleOutputValue - a VALUE-shaped route that cannot carry a deferred parent read, because a ParentRef is not a cty.Value. #346’s fix is part-shaped and lives on the identity-argument route. A separate mechanism is needed and is filed separately. Also corrected: this file previously recorded run.sh’s stage-3 assertions as stale (WANT_CIDX_N=7). They are not, and were not at this commit - the committed script already asserts WANT_CIDX_N=0, WANT_DEFAULT_N=0, WANT_UNRESOLVABLE_N=0, WANT_MODOUT_N=1 and WANT_CASCADE_N=1, which is exactly what the run produced, so the script exits 0 while the estate stays blocked. PRIOR HISTORY BELOW. Landed c239792018/47778a931a (2026-08-18); migrate’s fail->pass flip was re-verified 2026-08-18 against current main (cec3c4b9b1) but the committed run.sh still asserted the stale pre-fix ‘0 eligible’ shape as a passing control rather than a real check. Follow-up pass 2026-08-18 (this entry) rewrote run.sh’s own assertions to the real, current numbers, re-verified for real in a fresh isolated worktree rather than trusted from the prior note: stage 2 dry run reports ‘23 of 39 resource instance(s) are eligible for stamping (VERIFIED or DRIFTED)’ (18 VERIFIED + 5 DRIFTED), -approve reports ‘23 resource(s) newly stamped, 0 already stamped, 0 failed, 16 skipped’, and the primary aws_db_instance’s tofu-address/tofu-estate tags are asserted by exact value straight through the AWS CLI (module.db.module.db_instance.aws_db_instance.this:0 / rds-complete-postgres). The 16 skipped: 13 untaggable by design (aws_route_table_association x9, aws_route, aws_security_group_rule, aws_iam_role_policy_attachment, random_id - no tags argument in the provider schema) and 3 are #305’s still-open unadmitted-type gap. test_plan is now asserted against a real live-plan on the really-migrated estate (state file deleted first) with a BREAK=1 negative control, and the real counts differ from what the prior note here claimed: exactly 7 count-index-in-tag sites (#304, all aws_security_group_rule.ingress_with_cidr_blocks) and exactly 3 unadmitted-type sites (#305, the three default-object adopters actually created), not 35 and 5. The prior note’s 35/5 figures were measured before this estate had ever actually been migrated (nothing tagged, so the 28 module.vpc sibling-indexing sites it also counted never had anything to resolve against) and before bc9ef26638 (‘a resource block with a provably-zero count/for_each has no instance to refuse admission on’, already on main) landed, which independently stops aws_default_vpc/aws_vpn_gateway_attachment’s two count=0 sites from refusing at all - together accounting for the 35->7 and 5->3 drop. Two unrelated real floci gaps found and filed upstream on the fork: lex00/floci#51 (RDS cross-region backup replication), lex00/floci#52 (SecretsManager RotateSecret wrongly requires a Lambda ARN for RDS-managed rotation) - both worked around in the script with documented EMULATOR GAP deltas so stage 1 could stand up at all. Follow-up pass 2026-08-18 (#313 cross-check, fresh worktree, real run): confirmed the 7 count-index-in-tag sites above are NOT #313’s wall. This estate’s data.aws_availability_zones usage only feeds local.azs = slice(…, 0, 3), a statically-known length, never a for_each/count keyed on the AZ name values themselves, so #313’s static-context diagnostic cannot fire here (grepped the full raw plan output: zero occurrences). Commented on #313 (ruling this estate out, with the slice-vs-for_each distinction as evidence) and re-confirmed #304 is still the sole test_plan blocker. Follow-up pass 2026-08-19: #304 fixed and merged (69038634d0/9aaca0ee10) - internal/live/lint/count_index_domain.go’s domain check was evaluating a whole module-call-argument value as one pass/fail unit, so one refused reference anywhere inside a list-of-objects argument poisoned every attribute derived from any part of it, even ones that never read the refused field. New StaticEvaluator.EvaluateStructural/EvalContextTolerant validate each reference individually. Re-verified for real: count-index-in-tag sites on this estate 7->0. Estate still does NOT reach test_plan clean, though: 14 sites (from_port/to_port/protocol/cidr_blocks) now fail a DIFFERENT diagnostic, ‘Identity not resolvable from configuration’ - internal/live/identity/partialargs.go’s tolerantVariables deliberately covers only count/for_each key-set resolution, not per-attribute identity-value rendering (its own doc comment records a past regression from broadening it carelessly). Filed as #323, not attempted - needs its own scoped pass. Plus 18 genuinely-ambiguous element(aws_subnet.[].id, count.index) sites, confirmed still correctly refusing (unweakened by #304’s fix). #304 left open (not closed) since the titled bug is fixed and verified but this estate still doesn’t reach a clean plan for the separate #323 reason. Follow-up pass 2026-08-19 (#321 re-verification, scouting only, no commit): #321’s fix generalizes strongly to this second, independent estate - 15 of the 18 element() sites now resolve cleanly (every aws_route_table_association.{public,private}.subnet_id/route_table_id). 3 remain: aws_route_table_association.database’s route_table_id goes through coalescelist(A[].id, B[].id) wrapping the splat, outside resolveElementCall’s bare-splat requirement - the same out-of-scope shape #321’s own closing comment already flagged, now confirmed reaching a second real module composition. One NEW site found: aws_security_group_rule.ingress_with_cidr_blocks[0].security_group_id via local.this_sg_id = concat(A..id, B..id, [""])[0] - concat()+splat+index through a local value, terraform-aws-modules/security-group’s universal accessor, high-leverage since every rule resource that module creates uses it. Both new shapes filed as #324, not attempted. #323’s 14 sites confirmed unchanged in count, root cause refined: this estate’s trigger is cidr_blocks = module.vpc.vpc_cidr_block (a module-output reference into a resource’s config-derived attribute) poisoning the whole variable projection, not the lookup()-into-bundled-table pattern #304 fixed - same tolerantVariables scope boundary, a second concrete trigger. Net: test_plan stays fail, 18 diagnostic sites total (4 unresolvable-identity + 7 module-output-static + 7 compute-static, mapping to #324’s 4 sites + #323’s 14). Three separately-scoped resolver passes stand between this estate and five-of-five, not one. live/e2e/corpus-rds-complete-postgres/run.sh’s stage-3 assertions are now stale (still expect #304’s old 7-site count-index picture) and need a real update pass, not done here. Follow-up pass 2026-08-19 (#324 item 2 fixed and merged, 80d3766b3e/79ffbe4732): concat(A[].id, B[].id, [literal])[N] through local.this_sg_id now resolves generically (reuses #321’s own splat/instance-count machinery, handles both the RelativeTraversalExpr and IndexExpr parse shapes HCL produces for a constant vs non-constant index). Confirmed by real absence from this estate’s own stage-3 output. Generalizes hard: refusal-probe over the full 250-entry offline corpus shows ‘Identity not resolvable from configuration’ 67 -> 42 (-25 sites), zero regressions, 15 offline corpus entries improved (all terraform-aws-rds examples, plus autoscaling/complete, ecs/complete, ecs/ec2-autoscaling, lambda/with-vpc-s3-endpoint - offline corpus entries, not necessarily live-crossed estates; corpus-security-group-complete and eks/examples/* unchanged). Item 1 (coalescelist) explicitly left open, unattempted. This estate itself: fixing the concat site surfaced a SEPARATE, previously-masked cascade - module.vpc.vpc_cidr_block feeding module.security_group’s var.ingress_with_cidr_blocks, ‘Module output not supported in static context’ - likely another instance of #313’s own deliberately out-of-scope resource-attribute boundary (the same family as corpus-security-group-complete’s remaining 7 sites), not yet formally confirmed as such or filed separately. test_plan stays fail; the estate’s own crossing script needs a real staleness-update pass (still asserts #304’s old picture) before its true current diagnostic count can be read cleanly. Follow-up pass 2026-08-19: #324 item 1 (coalescelist) also fixed and merged (c25957cbdf/49744a5617) - #324 now fully closed, both items. The exact 3 aws_route_table_association.database sites this issue named are confirmed gone from this estate’s real live-plan output. Generalizes narrowly but cleanly beyond this estate: refusal-probe shows -14 sites across exactly 2 offline corpus entries (cross-region-replica-postgres, vpc/examples/issues - the latter matching #321’s own predicted 8-site count exactly). test_plan still stays fail here - blocked only by the pre-existing, unrelated module-output cascade already noted (likely #313’s family, unconfirmed) and #323’s still-open 14 sites. All of #321/#324’s derivable element/splat/concat/coalescelist work is now done across this estate; what remains needs #323’s own dedicated pass plus resolving the module-output cascade, not further quick derivations. Follow-up pass 2026-08-19: #323 fixed and merged (3d62366625/fb95168e63), closed. tolerantVariables now resolves a static leaf independently of a sibling leaf’s genuine unresolvability, instead of the whole variable projection being poisoned by one bad reference - traced to configs.staticScopeData.GetInputVariable’s own error bail discarding every known leaf along with the one genuinely unknown one. Real crossing re-verified: stage-3 identity refusals 14 -> 2 (both are the SAME underlying cause counted twice - module-output-not-supported and unable-to-compute-static-value both trace to cidr_blocks = module.vpc.vpc_cidr_block -> aws_vpc.this[0].cidr_block). CONFIRMED: this estate’s sole remaining test_plan blocker is #313’s root cause B (a resource-attribute reference through a module output), the exact same maintainer-scoped-out boundary blocking corpus-security-group-complete’s own last 7 sites - not a bug, not derivable further, a pure scope decision. Generalizes cleanly: refusal-probe -204 sites across 14 offline corpus entries (11 rds examples, 2 ecs examples, autoscaling/complete), zero instances gained/lost anywhere, zero regressions - improves diagnostics, unblocks nothing further by itself (as expected, since the poisoning fix doesn’t touch the genuinely-unresolvable leaf). run.sh’s stage-3 assertions are now confirmed stale in a new way too: WANT_CIDX_N=7 has actually been 0 since #304 landed, not just uncounted - needs a real update pass reflecting the estate’s true current picture (count-index 0, unadmitted-type 0, both remaining diagnostics tracing to the single #313-root-cause-B leaf), deliberately left to the orchestrator’s own call rather than the fixing agent’s.
Reproduce it#
go run ./tools/gauntlet run corpus-rds-complete-postgresNeeds 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-rds-complete-postgres/run.sh; BREAK=1 corrupts its assertions to show they are load-bearing.