datacite/mastino, global/dns - DataCite’s own global DNS root module (.corpus/mastino/global/dns)

Source: https://github.com/datacite/mastino.git at 4d8c1f1bebd91e73195017ce44a243002e9e36e5.

Set: growing. Lane: published-deployment.

Not clear yet.

Last run at commit 2b52ff8eb7 on 2026-08-25T17:36:46Z, exit code 0.

DataCite’s own global DNS root module, the largest offline-clean estate (63 instances) that had never touched a cloud. 2 of 5 - and the two stages it does not reach are blocked on one real, general, previously-unrecorded choudoufu defect, not on anything specific to this estate. Still offline-clean when crossing started (refusal-probe -schemas: blocked 0 sites 0 instances 63 at c41279989a); the schema-less mode disagrees (blocked 1 sites 2, both render correctly in the real run - HANDOFF’s asymmetry caveat firing on a live estate). Two of team-members-access’s four deltas recur (#268 mandatory backend edit, in cloud{} form; #269 provider version skew, ~> 5 -> 5.100.0 with no list resources, all four zones ServerAssigned); the other two do not (one data source answered by an out-of-band VPC; an ordinary emulator override). Two NEW walls: (1) estate-owned, not choudoufu’s/floci’s - the four *-ns blocks manage each zone’s own apex NS set, which Route 53 creates itself, so a from-scratch apply dies with InvalidChangeBatch; fixed with allow_overwrite=true, the same argument the estate’s own author already writes on wp-prod-staging. (2) Filed as #341: stage 3’s entire plan is 0/14/0, every diff line +allow_overwrite=true (10 of 14 on wp-prod-staging[0..9], carried in DataCite’s own text with no deltas needed) - #275’s residue mechanism populates and reads back the record store for TAGGABLE resources only (4 zones get ‘filled 1 residue attribute(s)’), but none of the 59 untaggable record sets do, because internal/live/liveimport/ratify.go’s !taggable() branch returns before the ReadResource that builds the *eligible object residue needs, and Approve’s recordResidueFor sits past the continue that skips a resource with no *eligible - one carrier serving two unrelated jobs, and untaggability should only disqualify one of them (the tag write, not the residue read). 342 of 1025 admitted types are untaggable and share this exclusion. Not fixed here - out of scope for a crossing pass. What the run DOES prove: all 63 rendered identities correct and distinct by value against the AWS CLI’s own answer, including two same-named datacite.org zones (public/private) that did not swap and ten wp-prod-staging[0..9] instances rendering staging3..staging12 individually. The 59 untaggable record sets are 94% of the estate - the widest derived-from-tagged fan-out in either lane. Script exits 0 only on reaching exactly this blocker (asserting the changed-address set, that allow_overwrite is the only attribute in the whole diff, and the 0/14/0 totals line) and non-zero on anything else including an empty plan, which is the signal to promote this entry to five stages once #341 lands. BREAK=1 verified red at exactly the identity assertion (a swapped zone id). Also filed lex00/floci#81 (floci accepts a record set whose name is outside its hosted zone, a real bug in the estate’s own text; blocks nothing here but is the shape where a crossing passes on the emulator and fails on real AWS). Suggested a new ‘published-deployment’ lane, distinct from terraform-popular/opentofu-native/reference, since this is neither a module example nor an OpenTofu-native project but a company’s own live TFC-connected infrastructure. Merged d5e592d67c (crossing e74b6e5c01); just demo-corpus-mastino-dns, port 4731. just ci green (exit 0, read from a file). Follow-up pass 2026-08-20 (#341 fixed and merged, c73a6e4617/78c92ad64a): FIVE OF FIVE, real. Fix is a third carrier (residuable, which eligible now embeds) built for any admitted-untaggable instance with a record_store declared, deliberately with NO ReadResource at ratify time - a residue attribute is by definition one no read returns, so state already has everything the fix needs, and skipping the read means an untaggable instance can never come back MISSING/DRIFTED (a concern the issue itself raised). Verdict stays StatusUntaggable/OutcomeSkipped; only the marker write was ever skippable, not the residue write. Corrected denominator along the way: DefaultTable holds 1040 rows, not 1025 - survey-full.json calls 683 taggable/342 untaggable and doesn’t cover 15 at all. Real re-crossing: migrate reports 4 stamped/59 UNTAGGABLE/14 residue records (all 4 zones plus 10 of the 59 record sets, matching the bug’s own signature exactly); test_plan EMPTY, all 63 identities asserted by value; test_apply a genuine no-op with all 14 residue records and 4 markers unchanged; drift_reconverge drifts wp-prod-staging[0]’s TTL (untaggable AND residue-carrying) and reconciles exactly that instance, BREAK_STAGE5=1 verified failing. One honest caveat: stages 4/5 had to be WRITTEN (the prior entry’s header claimed they existed in git history but e74b6e5c01 is the file’s only commit), and the verifying run itself executed in two calls after a SIGTERM mid-init, not one continuous process - same container/workdir throughout, but the committed script has not been run start-to-finish in a single invocation. A real, separate, more urgent finding surfaced while verifying: #340’s own change to live-import’s summary line ("%d newly recorded, %d already recorded" inserted mid-line) broke the exact-string assertion in 19 OTHER crossing scripts on main - invisible to just ci since e2e scripts aren’t in that tier. Filed as #342 with the full list and the one-line fix each needs.

Reproduce it#

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