OvertureMaps/terraform-aws-overture-tiles (Overture Maps Foundation), pinned by tag AND commit (v1.2.0, 3f44cebc297db8626705e99784f412b4a2c4eda1) - the first OpenTofu-native lane entry with a real tagged release to pin against
Source: https://github.com/OvertureMaps/terraform-aws-overture-tiles.git at v1.2.0.
Set: core. Lane: opentofu-native.
Why it is in the core set: a real project built for OpenTofu specifically, so OpenTofu-only surface is exercised
Clear. Every headline stage passes.
| Stage | Verdict | Duration | Detail |
|---|---|---|---|
| Cold deploy | pass | 55s | 26 resources, genuinely cold, genuinely unmarked |
| Migrate | pass | 1m9s | 16 of 26 stamped, 0 failed; the other 10 correctly UNTAGGABLE or already-ruled UNADMITTED_TYPE |
| Replan from nothing | pass | 9s | live-plan empty after the STAGE 2d convergence apply; S3 bucket and OAC identities re-checked by value against the AWS CLI |
| No-op apply | pass | 3s | no-op apply (0 added, 0 changed, 0 destroyed); 16 tagged objects before and after (resourcegroupstaggingapi’s cross-service search alone, floci#98 fixed); S3 bucket and OAC identities unchanged; record store intact |
| Drift and reconverge | pass | 7s | one object tampered (VPC Name tag), exactly module.overture_tiles.aws_vpc.batch[0] proposed by both choudoufu and stock with the identical change, apply changed 1 and the Name tag reads back as configured |
| Rename | pass | 47s | moved block: module.overture_tiles renamed to module.overture_tiles_moved via ONE module-level moved block, 0 add/0 destroy, 16 real tag-marker rewrites (plan showed 18 - two untaggable siblings’ policy JSON transiently ‘known after apply’, resolving to no real change at apply time, confirmed via the stage-5 marker/propagation filter and by value); live-mv: module.overture_tiles_moved renamed to module.overture_tiles_final across 14 of 16 taggable children, one call each, zero churn - the other 2 (aws_batch_compute_environment.tiles and aws_iam_instance_profile.ecs, both server-/provider-assigned identities with no List support in the provider) correctly refused by live-mv and renamed via their own moved blocks instead, applied cleanly; the nine untaggable/config-derived children and the UNTAGGABLE OAC (no longer UNADMITTED_TYPE - #249 narrowed) did not move at all; stock oracle over the identical module rename on cold_deploy’s own state also shows zero churn via its own single module-level moved block, covering every one of the 26 children including the two live-mv cannot |
| Remove a block | pass | 52s | choudoufu: create_cloudfront_distribution=false proposed exactly two destroys plus one in-place update (0 add, 1 change, 2 destroy: the distribution, its untaggable OAC, and the bucket policy’s own CloudFrontOAC statement dropping), applied cleanly (0 added, 1 changed, 2 destroyed), the distribution 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 cold_deploy’s own state also proposes exactly the same two destroys plus the same bucket-policy update |
| Change count | pass | 47s | choudoufu: scaling aws_security_group.count_test from 2 to 1 destroyed exactly count_test[1] (0 add, 0 change, 1 destroy), leaving count_test[0]’s live GroupId (sg-74204f1930b130693) and its tofu-address marker (aws_security_group.count_test:0, colon-escaped per live/MARKERS.md) unchanged, both read back through the AWS CLI; scaling back from 1 to 2 created exactly count_test[1] (1 add, 0 change, 0 destroy) under a NEW GroupId (sg-750febfa0767c2a92 -> sg-ed40861287840dbdc) carrying tofu-address=aws_security_group.count_test:1, while count_test[0] stayed untouched throughout; every absence check reads length(SecurityGroups) through a group-id FILTER, because describe-security-groups –group-ids on a deleted id returns an empty list with exit 0 on this emulator pin; the next stateless live-plan is empty. Stock oracle (G0): the identical 2-instance block stood up with plain tofu in its own working directory against the same idle endpoint shows the identical shape - destroy the higher index only (0 add, 0 change, 1 destroy), create the higher index back under a new GroupId (1 add, 0 change, 0 destroy), the lower index’s GroupId unchanged both times - then torn down (3 destroyed) before the choudoufu side ran. SYNTHETIC BLOCK, and why: every count this module declares is a boolean create toggle (create_vpc x7, create_s3_bucket x4, create_cloudfront_distribution x2, three launch_template variants gated on existing_id == null), never a scalable set, so scaling one is the day2_remove shape this script already runs, not a shape with a survivor; and its one real for_each (aws_batch_job_definition.tiles over toset(var.themes)) is scoped by this crossing’s own root config to a single theme from stage 1 onward, so it has nothing to scale down to and widening it would move every earlier stage’s counted assertions (26 resources, 16 stamped, 16 tagged objects, day2_rename’s own 16-address list). What shrinking that set would plan is not claimed: it was never measured, because it was never a usable option. Sanctioned fallback per live/GAUNTLET.md #8, precedent reference-ec2-vpc Part F and corpus-iam-policy Part G. It reuses a type this estate already exercises (aws_security_group.batch), sits at a root address nothing else names, and runs entirely after day2_remove, so no earlier stage’s assertions move. BREAK_COUNT=1 asserts the WRONG instance (count_test[0]) was destroyed and correctly reports fail. |
| Replace with create_before_destroy | pass | 7s | choudoufu: supplying module.overture_tiles_final’s name_overrides.cloudwatch_log_group proposed exactly one replace at the same declared address (the log group; -/+ destroy and then create) cascading into two expected in-place updates (the execution role’s inline log policy, the job definition) and nothing else; applied cleanly; the old object (/aws/batch/overture-tiles-crossing) is confirmed gone and the new object (/aws/batch/overture-tiles-crossing-v2) carries the marker, both via the AWS CLI; the local record store’s record at the same address now names the new object’s import_id, not the destroyed one (/aws/batch/overture-tiles-crossing -> /aws/batch/overture-tiles-crossing-v2); the next plan proposes no resource action; stock oracle on cold_deploy’s own state (F-ORACLE) also proposes exactly one replace at the same address plus the same cascade (plan only, not applied); BREAK=replace confirms a manufactured marker collision is reported loudly rather than silently proposed as nothing. Scope note: this exercises OpenTofu’s default destroy-then-create ordering, not the create_before_destroy variant the stage’s Title names - see this section’s own header comment. |
| Crash between create and destroy | not run | ||
| Teardown | not run | ||
| Plan, review, apply | pass | 12s | one argument edited (module.overture_tiles’s cors_allowed_origins, [""] -> [“https://tiles.example.invalid”], which reaches module.overture_tiles.aws_s3_bucket_cors_configuration.tiles[0] and nothing else - it is the only root knob of this 26-instance estate that lands on exactly one instance IN PLACE, since tags reaches all 16 taggable children at once, name_overrides and the launch template are ForceNew, and the create_ toggles are creates and destroys), “plan -out=approved.tfplan” wrote a 34027-byte stock-format plan file whose whole change set is that one in-place update; the world then moved out of band (vpc-401f59ad’s Name tag -> moved-after-approval, this estate’s own STAGE 5 mutation lifted, through the AWS CLI and never through choudoufu) 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 the extra row as " module.overture_tiles.aws_vpc.batch[0] Update vpc-401f59ad" - both module.overture_tiles.aws_vpc.batch[0] and the live vpc-401f59ad it was computed against - with “Exit status 3” spelled out for a pipeline; nothing was applied - overture-tiles-crossing-tiles’s CORS rule still read “” through s3api get-bucket-cors rather than from 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 Name tag put back and nothing else changed, the IDENTICAL file applied - 0 added, 1 changed, 0 destroyed - and the CORS rule read back as https://tiles.example.invalid, so the refusal is earned by the drift and not handed out to every plan file. Reverted and reconverged in P5 (CORS back to “”, VPC Name tag still overture-tiles-crossing-vpc, next plan proposes no resource action, no state file left behind) so PART D 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 | 1m57s | 26 resources from nothing, bucket and batch job queue markers verified via the AWS CLI, 26 records in the local record store (#364 A2), replan empty, stock oracle in its own namespace matches structurally (batch job queue state, CloudFront distribution comment, bucket count) |
| 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 7m6.3s.
Oracle: stock terraform 1.16.1, stock tofu 1.12.6 (matches the current pin).
Landed 2026-08-19. Sourced via GitHub code search rather than the awesome-opentofu/Powered-by-OpenTofu lists, which turned out to be pure tooling/adopter lists with no deployable estates. OpenTofu-native evidence is in its CI rather than a genuine .tofu extension (weaker self-description than corpus-hongbomiao, which ships real .tofu files): .github/workflows/ci.yml runs tofu fmt/validate/test/tflint exclusively through opentofu/setup-opentofu - terraform never appears - and its tests use OpenTofu’s own mock_provider framework. A real, tagged-release module (v1.0.0->v1.2.0) from a Linux-Foundation-adjacent geospatial project backed by AWS/Meta/Microsoft/TomTom, contributor fixes as recent as 2026-05-21. cold_deploy genuinely passes (26 resources, plain tofu apply, unmodified module). migrate is BLOCKED, not clean: live-import stamps 13 of 26 cleanly, 10 correctly UNTAGGABLE or already-ruled UNADMITTED_TYPE (#249), and 3 AWS Batch resources fail to stamp on a real floci bug - TagResource/UntagResource/ListTagsForResource (POST /v1/tags/{resourceArn}) misroutes to AppSyncController’s greedy catch-all since BatchController never registers that path. Filed as lex00/floci#72 with full evidence (checked ~/checkouts/floci first, confirmed same bug on current main, no in-progress fix) - not fixed, per this session’s standing instruction. test_plan is BLOCKED, deterministically asserted (Plan: 4 to add, 7 to change, 0 to destroy, every line traced) rather than reached cleanly. Also filed INTENTIUS/choudoufu#322: aws_iam_role_policy (untaggable, ServerAssignedIfAbsent name via name_prefix) escalates a single-address unbound warning into a hard Error: Listed resource with no tags that aborts the ENTIRE live-plan, not just its own address - a real blast-radius concern (one bad site takes down the whole plan) worth prioritizing. Not fixed; worked around in this crossing via the module’s own name_overrides input so the script could still assert what it could reach. Stages 4-5 not attempted - both need a genuinely empty first plan, which this estate doesn’t reach yet. Confirmed informationally that applying the current non-empty plan fails safely (AWS Batch’s own name-uniqueness check refuses the duplicate) rather than silently corrupting anything. Merged to local main as a233497312 (fix itself: 3c183a305a); justfile gained recipe demo-corpus-overture-tiles; live/corpus-manifest.json gained the pin. UPDATE 2026-08-20: lex00/floci#72 FIXED (floci 1d469fff, published; choudoufu re-pinned to sha256:dc246b1e) and migrate now genuinely PASSES - re-run for real against that image, not inferred: 16 of 26 newly stamped, 0 already stamped, 0 newly recorded, 0 already recorded, 0 failed, 10 skipped, where it was 13 stamped / 3 failed before. The dry run’s own counts are unmoved (16 eligible, 11 VERIFIED, 5 DRIFTED, 9 UNTAGGABLE, 1 UNADMITTED_TYPE) - the bug was in the tag WRITE, never in verification. The fix is generic rather than Batch-shaped: floci already had a SharedTagsController dispatching /tags/{arn} to the TagHandler whose serviceKey matches the ARN’s own service segment, and AppSync had simply claimed /v1/tags/{arn: .+} for itself; the fix lifts that dispatch into a SharedTagsDispatcher keyed on path prefix AS WELL AS service, adds a SharedTagsV1Controller, and converts AppSync into a TagHandler beside a new BatchTagHandler - so any further service on that path needs only a handler. Stage 2c now asserts three markers through the AWS CLI instead of one, including the Batch job queue’s own tofu-address/tofu-estate via batch list-tags-for-resource (the very call that used to be answered by AppSync) and that the module’s own create-time Project tag SURVIVED the stamp - a TagResource that replaces instead of merging is how a live object silently loses its markers. INTENTIUS/choudoufu#322 item 1 is also fixed (576990a599/b75e46c24e) and is no longer the test_plan wall. test_plan stays ‘fail’ but the wall MOVED and is now harder: it is no longer a non-empty plan, it is live-plan refusing to plan at all (exit 1, no plan produced), at exactly two diagnostics - ‘Invalid Identity Attribute Value: Identity attribute “arn” contains an Account ID “000000000000” which does not match the provider’s “”’ followed by its consequence ‘Cannot import for projection’. Filed as INTENTIUS/choudoufu#345 with full evidence. Reachable only BECAUSE the Batch resources are now stamped: projection imports one by its ARN identity and hashicorp/aws validates an identity ARN’s account segment against the account the provider knows about itself, which skip_requesting_account_id = true (what every crossing script sets to reach a local emulator) leaves empty. The marker is not wrong - stage 3 re-reads the job queue’s real ARN from floci through the AWS CLI and asserts the refusal names that exact string. MEASURED, NOT ASSUMED, and recorded in the script’s header so it is not re-tried: setting skip_requesting_account_id = false on the estate copy alone clears this error and breaks stage 2 instead, because the provider then routes S3 bucket tag reads through S3 Control’s account-prefixed virtual host (dial tcp: lookup 000000000000.127.0.0.1: no such host), taking aws_s3_bucket.tiles[0] from VERIFIED to MISSING and the estate to 15 of 26 eligible. Stages 4-5 still not attempted: they need a plan and stage 3 produces none. The script’s stage 3 is rewritten to assert the new wall deterministically (nonzero exit, exactly 2 errors and no more, both texts, the ARN in them) - and a ZERO exit now fails it, so the day this is fixed the script says so instead of quietly passing. BREAK=1 (stage 2’s bucket-marker control) was NOT re-run this pass; its mechanism is unchanged. UPDATE 2026-08-20 (INTENTIUS/choudoufu#345 FIXED, no floci change): the identity-ARN crash is gone. The obvious fix, skip_requesting_account_id = false on the estate copy, was re-measured for real and its earlier ‘breaks stage 2 via S3 Control’s account-prefixed virtual host, dial tcp: lookup 000000000000.127.0.0.1: no such host’ failure is a DNS failure, not an HTTP one - confirmed by curling the same account-prefixed host directly, which fails identically before any TCP connection, so no floci server-side Host-header routing could ever have fixed it (the request never arrives). The real fix is ENDPOINT: floci already publishes localhost.floci.io as a real, public wildcard DNS domain (EmbeddedDnsServer.DEFAULT_SUFFIX, same mechanism as LocalStack’s localhost.localstack.cloud) that resolves an account-ID-prefixed label to 127.0.0.1 with no floci container running at all - confirmed via dig and via curl reaching floci’s S3ControlController correctly (path-based dispatch, unaffected by the account-prefixed Host). Verified against the CURRENT, unmodified floci image (be3f7ffd, sha256:8a882bcc - no re-pin, no floci commit, no floci PR). Real re-run: stage 1 PASS unchanged (26 resources). Stage 2 PASS, counts moved by exactly one resource as a direct, expected consequence (11 VERIFIED/5 DRIFTED -> 10 VERIFIED/6 DRIFTED: aws_launch_template.batch[0]’s arn now differs between the PLAIN state, written under skip_requesting_account_id = true and so account-less, and the ESTATE copy’s live re-read, which now knows its account - a real difference between two provider configurations, not a wrong marker). Stage 3 (test_plan) still recorded fail by this repo’s own convention (a first plan must be empty to pass) but the #345 wall itself - live-plan exiting 1 with two diagnostics and no plan at all - is gone: live-plan now exits 0 with ‘Plan: 1 to add, 7 to change, 0 to destroy.’, asserted deterministically address-by-address. Every line traces to an already-tracked or by-design cause, none of them new: the 1 add is the already-ruled #249 aws_cloudfront_origin_access_control UNADMITTED_TYPE gap; 6 of the 7 changes are internal/live/discovery/count.go’s own documented one-time tofu-slot migration-visibility tag (bindCountByAddress’s doc comment: ‘visible in the plan as a tofu-slot tag being added to each member’ - by design, cements on first apply), on every count-toggled ([0]) resource this module declares; the 7th, aws_s3_bucket_policy.tiles[0], is a content diff cascading from the new OAC’s arn being ‘known after apply’ in the same plan. Verified informationally (not scored, per this repo’s own convention that test_apply is scored only once test_plan is itself empty): applying the stage 3 plan succeeds (Apply complete! Resources: 1 added, 6 changed, 0 destroyed - matching the plan), and a second live-plan afterward is genuinely empty (‘No changes. Your infrastructure matches the configuration.’) - the estate converges in exactly one apply, confirming #345’s own header claim. No Go code touched; the fix is entirely live/e2e/corpus-overture-tiles/run.sh (ENDPOINT changed from a bare IP to localhost.floci.io, skip_requesting_account_id parameterized so only the estate copy sets it false, cold deploy left untouched).
Reproduce it#
go run ./tools/gauntlet run corpus-overture-tilesNeeds 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-overture-tiles/run.sh; BREAK=1 corrupts its assertions to show they are load-bearing.