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

Not clear yet.

Last run at commit 3aa44293e6 on 2026-08-25T17:54:35Z, exit code 0.

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-tiles

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