terraform-aws-modules/terraform-aws-s3-bucket examples/complete (tag v5.9.1), its flagship example

Source: https://github.com/terraform-aws-modules/terraform-aws-s3-bucket.git at v5.9.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.

Last run at commit fa5a6bd3bd on 2026-08-25T17:34:52Z, exit code 0.

Landed 1398574b03 (2026-08-18); re-verified for real 2026-08-18 in an isolated worktree against local main bcf78bacbd, full pipeline reproduced clean twice in a row. #306 is fixed (lex00/floci S3ControlController.tagResource now reads-merges-writes; reconciled into the currently-pinned floci image; internal/live/lifecycle/marker_tag_merge_live_test.go’s TestMarkerSurvivesIncrementalTagUpdate passes live against it). DELTA 6 (the tags-removal workaround) reverted - module.s3_bucket’s real tags = { Owner = “Anton” } is back, unmodified, and the stage 2c residue-classification apply leaves all four buckets’ markers intact with it restored. DELTA 5 (expected_bucket_owner) is UNCHANGED, for a reason independent of #306: it is ForceNew on most of these sub-resource types with no live representation at all (a request-header assertion, not a stored property), so a discovery-rebuilt prior would force a real replace on the very first onboarding apply - the same shape as DELTA 3’s random_pet. The prior investigation’s other open question - module.s3_bucket’s canned acl and website.routing_rules - was checked for real rather than assumed fixed, and DOES still block test_plan after #306’s fix, confirmed reproducibly. Traced past “the provider’s Read() needs a genuinely-remembered prior” (the prior investigation’s framing, which attributed this to #306 too - a conflation this session’s trace evidence rules out, since the mechanism is unrelated to tags/floci entirely): issue #275’s residue mechanism (internal/live/projection/residue.go) DOES run here and DOES try to classify acl - TF_LOG=trace on the stage 2c apply shows ‘residue candidate “acl”: readA=cty.StringVal(“private”) readB=cty.StringVal(“private”) applied=cty.StringVal(“private”)’, and classifyResidue’s own documented rule reads that as “the provider answers this from the remote”, so nothing is recorded as residue. Yet the SAME attribute, read moments later by internal/live/projection/build.go’s importAndRead (the function stage 3’s plan actually uses), comes back empty and proposes ‘+ acl = “private”’. The two reads disagree because their prior is built two different ways: residue.go’s identityOnly nulls every non-identity attribute outright, while importAndRead’s prior is whatever provider.ImportResourceState() returned - a zero-value stub (acl = “”, not null) for this SDKv2 resource. The provider’s Read() treats an explicit null differently from an SDKv2 zero-value string for this attribute; reconciling the two prior constructions is real work but importAndRead is the read path every projected resource in this fork goes through, so a fix needs corpus-wide validation, not a one-estate patch - out of scope here. SCOPED OUT instead (module.s3_bucket’s acl and website inputs removed, applied to BOTH the cold-deploy and choudoufu copies so the crossing tests one genuinely-reduced estate throughout, not choudoufu silently abandoning management of something the cold deploy still created) - same discipline corpus-sumaform-aws uses for its own two structural refusals. Estate is now 30 instances across 14 aws_s3_bucket_* types (down from 32/15; aws_s3_bucket_acl survives elsewhere via module.cloudfront_log_bucket’s own grant/owner-driven ACL). Also hit and fixed IN THIS SCRIPT (no choudoufu/floci change needed): THE OUTPUTS QUIRK already documented in corpus-iam-read-only-policy and corpus-root-dns-zones - module.s3_bucket’s outputs, re-exported at root, have no prior baseline across a stateless live-plan, so every run shows a permanent ‘Changes to Outputs’ section and OpenTofu’s renderer never prints a ‘Plan: N to add…’ line while that is true, empty of resource changes or not. Stage 3/5’s empty-plan assertions now check for the absence of a resource action header (‘will be (created|updated|destroyed)’) instead of grepping for ‘No changes.’/‘Plan: 0 to add…’, matching those two scripts’ own pattern; this was never exercised before since stage 3 had never previously reached an actually-empty-of-resource-changes plan. Also fixed the rendered-import-identity count check (N_IDS), which had silently never been exercised either: several of module.s3_bucket’s own sub-resource types (ownership_controls, versioning, policy, logging, cors_configuration, lifecycle_configuration, object_lock_configuration, public_access_block, accelerate_configuration, request_payment_configuration) import by the bucket’s own id alone, so after sort -u only 10 distinct strings remain for 30 instances - the raw (pre-dedup) occurrence count (29) is what actually approximates “one per instance” and is now what the sanity floor checks; the deduplicated set is still what ids_all_name_known_roots validates.

Reproduce it#

go run ./tools/gauntlet run corpus-s3-bucket-complete

Needs 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-s3-bucket-complete/run.sh; BREAK=1 corrupts its assertions to show they are load-bearing.