Evidence · How close AWS is

corpus-simpleinfra-dns

rust-lang/simpleinfra, terraform/dns (live/corpus-manifest.json) - the Rust project’s production DNS for seven domains it owns, crates.io included

Source: https://github.com/rust-lang/simpleinfra.git at 1f7f2e775a5bb567bc96b0f246f2e4656302b70c.

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

Clear. Every headline stage passes.

Stale: since the run recorded above, this estate’s own files have changed (live/e2e/corpus-simpleinfra-dns/run.sh differs from the version that run measured), and the shared protocol library live/e2e/lib that this script sources has changed (live/e2e/lib/gauntlet.sh differs from the version that run measured). Every verdict in the table above was measured against the earlier version, so a stage those edits fixed still reads fail here, and a stage they broke still reads pass; only a re-run of this estate settles it (#1264, #1292).

Stage	Verdict	Duration	Detail
Cold deploy	pass	1m32s	35 instances (7 zones, 28 records) from plain terraform, 0 of 7 zones carry tofu-estate
Migrate	pass	1m20s	7 stamped, 7 distinct hosted zones, one per module call
Replan from nothing	pass	15s	no resource change proposed, nothing foreign; all 35 rendered identities name a live hosted zone or record set
No-op apply	pass	39s	no-op apply (0 added, 0 changed, 0 destroyed); 7 zones / 28 records unchanged, all 7 markers unmoved
Drift and reconverge	pass	32s	one untaggable record drifted, exactly module.rustconf_com.aws_route53_record.cname[“2016”] proposed and applied, TTL reconverged to 300, 28 records and the parent marker intact
Rename	pass	40s	moved block: module.rustaceans_org renamed to module.rustaceans_org_moved with zero churn (0 add, 1 change, 0 destroy) - only the zone’s own marker rewritten, its 2 record children (A, CNAME) did not move; live-mv: module.cratesio_com (0 records) renamed to module.cratesio_com_final with zero churn, marker rewritten in place; stock oracle over the identical two-module rename on cold_deploy’s own state also shows zero churn (0 add, 0 change, 0 destroy), using per-child moved blocks stock’s own state-address tracking requires and choudoufu’s stateless untaggable-record derivation does not; both live zone ids unchanged, read via the AWS CLI
Remove a block	pass	36s	choudoufu: deleting module.cratesio_com_final’s block proposed exactly one destroy (0 add, 0 change, 1 destroy), applied cleanly (0 added, 0 changed, 1 destroyed), the hosted zone is genuinely gone from the live account (route53 get-hosted-zone on the old id now errors, read via the AWS CLI, not choudoufu’s own report; 7 zones down to 6), and the next plan proposes no resource action; stock oracle on cold_deploy’s own state (E-ORACLE) also proposes exactly one destroy for the same zone (before any rename ever touched it)
Change count	pass	1m15s	choudoufu: dropping “2024” from module.rustconf_com’s CNAME for_each map destroyed exactly module.rustconf_com.aws_route53_record.cname[“2024”] (0 add, 0 change, 1 destroy), leaving sibling module.rustconf_com.aws_route53_record.cname[“2022”]’s TTL and 27 remaining record sets untouched; adding it back created exactly the same key (0 add, 0 change -> 1 add, 0 change, 0 destroy), restoring its TTL/value and the 28 record-set count, while the sibling and the parent zone’s own marker stayed untouched throughout; the next plan is empty; a Route 53 record set carries no server-minted identifier of its own (verified directly against floci, no tofu in the loop: ListResourceRecordSets returns a byte-identical entry across a genuine delete/recreate, only ChangeResourceRecordSets’ own per-call ChangeInfo.Id differs), so the destroy is proven by verified ABSENCE rather than an id-diff, unlike this stage’s aws_iam_policy/PolicyId and EC2/VpcEndpointId precedents; the G-ORACLE stock oracle on the identical for_each change, plan-only on cold_deploy’s own state, shows the identical shape: destroy the dropped key only, propose creating it back, every sibling key untouched both times
Replace with create_before_destroy	pass	1m18s	choudoufu: changing module.areweasyncyet_rs’s ForceNew domain argument proposed exactly one zone replace at the same declared address, cascading into its one A record - 2 to add, 2 to destroy, matching F-ORACLE’s own plan shape; applied cleanly; the old zone (Z3BE6B3YW11MHZ8) is confirmed gone and the new zone (ZVPVCD2YPNNMLWB) carries the marker, both via the AWS CLI; the local record store’s record at the same address now names the new zone, not the destroyed one; the next plan proposes no resource action. No BREAK=replace leg - see this section’s own header comment (reusing corpus-security-group-complete’s own finding from this same unit rather than re-measuring it here).
Crash mid-apply	not run
Teardown	not run
Plan, review, apply	pass	1m6s	one argument edited (module.arewewebyet_org’s ttl 300 -> 600; that call declares exactly one record, the www CNAME, so one argument is one instance), “plan -out=approved.tfplan” wrote a 27549-byte stock-format plan file whose whole change set is one update on module.arewewebyet_org.aws_route53_record.cname[“www”] (“Plan: 0 to add, 1 to change, 0 to destroy”); the world then moved out of band (2016.rustconf.com.’s TTL set to 60 in zone ZA1TUB0AM8GB8TK through the AWS CLI, never through choudoufu - STAGE 5’s own proven mutation, on a DIFFERENT instance in a DIFFERENT hosted zone from the one under review) and “apply approved.tfplan” refused with “The approved plan no longer matches the live system” at exit 3, classifying the drift under “This apply would do, and the approved plan does not include:” and naming module.rustconf_com.aws_route53_record.cname[“2016”] together with the whole live identity it was computed against, ZA1TUB0AM8GB8TK_2016.rustconf.com_CNAME (this type’s ZONEID_NAME_TYPE import syntax, rebuilt in the script from the zone id, record name and type it already knew independently) - with “Exit status 3” spelled out for a pipeline; nothing was applied - www.arewewebyet.org. still read TTL 300 through the AWS CLI, which is stronger evidence than the absence of an “Apply complete!” line. Inverted control on the same run (the shape live/smoke/scenarios/apply-what-was-approved.sh reasons out): with the drifted TTL put back and nothing else changed, the IDENTICAL file applied - 0 added, 1 changed, 0 destroyed - and www.arewewebyet.org. read back at TTL 600, so the refusal is earned by the drift and not handed out to every plan file. The edit was then reverted, re-applied, the 28 record sets re-counted and the estate replanned empty, so PART F starts where it would have. BREAK_APPROVAL=1 asserts stage 12’s own recorded Break line (apply the planfile after a mutation and expect success) and correctly fails
Greenfield apply	pass	3m30s	35 instances from nothing (7 zones, 28 records), all 7 markers verified via the AWS CLI, replan empty, stock oracle in its own namespace matches structurally on all 7 zones (28 records)
Strict profile (not a headline stage)	not run
Plan with no local state (not a headline stage)	not run

Last run at commit f707182267 on 2026-10-02T19:42:52Z, exit code 0, against emulator image ghcr.io/lex00/floci@sha256:6c3d5c2dac72209e6f2e45c08902e783480d4d34f48d25daba8da94b9f882072. Stale: the current pin is ghcr.io/lex00/floci@sha256:ff46eb8d1b73a9727948d1a194a660972e44cc64164a486548da7cb468a09144. Total run time 12m44s. Oracle: stock terraform 1.16.1, stock tofu 1.13.0 (matches the current pin). Engine: OpenTofu base 1.13.0 (matches the current base).

35 instances: 7 aws_route53_zone TAGGABLE (7 markers, each verified against the domain that module call declares - a fact the marker does not supply), 28 aws_route53_record UNTAGGABLE and re-derived from their tagged parent zone. Found and corrected a census error in issue #274’s own thread first: live/e2e/repeated-module/run.sh has targeted this same directory since #280 but never runs live-import (grep -c live-import -> 0), applies with the live block already declared so genuinely unmarked infrastructure never exists, and has no drift stage - it is not a five-stage crossing despite being counted as one, though it does cover stages 3/4 well. Cold-deployed by real Terraform v1.15.8 (35/0/0), 7 stamped + 28 skipped by live-import -approve, state deleted, live-plan empty with all 35 rendered identities checked as strings against Route 53’s own answer, no-op apply 0/0/0 with all 7 markers unmoved. Stage 5 drifts an UNTAGGABLE object out of band - a record set’s TTL 300 -> 60 via change-resource-record-sets - which no other crossing’s drift stage does: with no state file and no tag on the object, the drift is only visible if the derived-from-tagged identity re-derived correctly. Plan proposes exactly module.rustconf_com.aws_route53_record.cname[“2016”] and nothing else; apply 0 added/1 changed/0 destroyed; TTL read back as 300. Three of team-members-access’s four deltas recur (#268 mandatory backend edit, #269 provider version skew ~> 5.64 -> = 6.59.0, an emulator provider override), asserted; the fourth (five seeded data-source reads) does not - 0 data blocks anywhere, asserted. One delta deliberately absent: the four trailing-dot record names (#281) are unchanged, asserted at count 4. BREAK=1 exits 1 at stage 2c on the corrupted marker; BREAK_STAGE5=1 exercises a real hole found on adversarial re-read - the first stage-5 assertion counted only will-be-updated addresses, so a destroy or create alongside the expected update would have passed silently under BREAK_STAGE5 (which skips the apply that would eventually have caught it) - fixed by asserting the plan’s own totals line first, mutation-checked (clean run reads exactly ‘0 to add, 1 to change, 0 to destroy’, BREAK_STAGE5=1 reads ‘0 to add, 2 to change, 0 to destroy’). Zero choudoufu defects found. A reusable methodology finding: any crossing whose cold deploy uses real Terraform (not tofu) cannot use corpus-giantswarm-crossplane’s lock-file-seeding fix for the 320s uncached-init tax, because terraform and choudoufu resolve providers from different registries (terraform.io vs opentofu.org) so neither’s lock file satisfies the other - measured here, plain terraform init >600s (timed out), -plugin-dir= 0.35s. -plugin-dir is strictly better than lock-seeding for tofu-cold-deployed estates too. justfile gained demo-corpus-simpleinfra-dns (port 4741); live/corpus-manifest.json gained the pin. Verified 2026-08-19 at 07b72f9977, 145s.

Reproduce it

go run ./tools/gauntlet run corpus-simpleinfra-dns

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