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.
| Stage | Verdict | Duration | Detail |
|---|---|---|---|
| Cold deploy | pass | 1m9s | 35 instances (7 zones, 28 records) from plain terraform, 0 of 7 zones carry tofu-estate |
| Migrate | pass | 39s | 7 stamped, 7 distinct hosted zones, one per module call |
| Replan from nothing | pass | 6s | no resource change proposed, nothing foreign; all 35 rendered identities name a live hosted zone or record set |
| No-op apply | pass | 12s | no-op apply (0 added, 0 changed, 0 destroyed); 7 zones / 28 records unchanged, all 7 markers unmoved |
| Drift and reconverge | pass | 22s | 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 | 16s | 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 | 25s | 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 | 51s | 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 | 1m8s | 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 (ZA8GNLCU2YAZBV9) is confirmed gone and the new zone (ZD5TC5HCUMMDNQ8) 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 between create and destroy | not run | ||
| Teardown | not run | ||
| Plan, review, apply | pass | 44s | 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 23450-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 Z4T1XW3A610OOKD 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, Z4T1XW3A610OOKD_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 | 2m30s | 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 |
Last run at commit 933618dec4 on 2026-09-08T22:17:50Z, exit code 0, against emulator image ghcr.io/lex00/floci@sha256:a39185cc3971d0188663d61043cb038dff1260d8a975b1aa72c4e2bb1feac3cb. Stale: the current pin is ghcr.io/lex00/floci@sha256:d9207de14c919f4bfa50e956376cc441970f3679aabfdd43f3dbf4b779b20805. Total run time 8m22.1s.
Oracle: stock terraform 1.16.1, stock tofu 1.12.6 (matches the current pin).
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=
Reproduce it#
go run ./tools/gauntlet run corpus-simpleinfra-dnsNeeds 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.