leynos/df12-www, the modules/monitoring module (pinned by commit alone - no tags published - e59eabba112b2a4c731123f26845a20f0ae0d938)
Source: https://github.com/leynos/df12-www.git at e59eabba112b2a4c731123f26845a20f0ae0d938.
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 | 6s | 3 resources added (2 alarms + dashboard), 0 objects carry tofu-estate=leynos-monitoring-crossing before migration |
| Migrate | pass | 24s | 2 of 3 stamped (1 skipped, untaggable dashboard), 0 failed; both alarm markers read back via the AWS CLI |
| Replan from nothing | pass | 2s | no resource change proposed; both alarms’ tofu-address unchanged, dashboard body re-derived and matches distribution_id |
| No-op apply | pass | 2s | no-op apply (0 added, 0 changed, 0 destroyed); object count unchanged at 2, no state file |
| Drift and reconverge | pass | 4s | S3 alarm’s alarm_description tampered, exactly 1 object proposed and applied, reconverged to its configured description |
| Rename | pass | 6s | moved block: aws_cloudwatch_metric_alarm.s3_requests_spike renamed with zero churn (0 add, 1 change, 0 destroy), marker rewritten in place; live-mv: aws_cloudwatch_metric_alarm.cf_requests_spike renamed with zero churn, marker rewritten in place; stock oracle over the same two-object rename on cold_deploy’s own state also shows zero churn (0 add, 0 change, 0 destroy); both live ids unchanged, read via the AWS CLI |
| Remove a block | pass | 5s | choudoufu: deleting the CloudFront alarm’s block proposed exactly one destroy (0 add, 0 change, 1 destroy), applied cleanly (0 added, 0 changed, 1 destroyed), the object is genuinely gone from the live account (describe-alarms on its name no longer returns it, read via the AWS CLI, not choudoufu’s own report), and the next plan is empty; classifyOrphans did not withhold the destroy because the S3-requests alarm, the surviving aws_cloudwatch_metric_alarm instance, is bound, not unclaimed |
| Change count | pass | 15s | choudoufu: scaling aws_cloudwatch_metric_alarm.count_test from 2 to 1 destroyed exactly count_test[1] (0 add, 0 change, 1 destroy), confirmed genuinely gone via describe-alarms (no server-minted id on this type - see header), leaving count_test[0] and its tofu-address marker unchanged; the local record store’s record for count_test[1] read tombstoned (has(“tombstone”), no current “identity”) at that same key, the #398-guard shape; scaling back from 1 to 2 created exactly count_test[1] under the SAME ARN (name/region/account-derived) with a fresh “identity” record entry (0 add, 0 change -> 1 add, 0 change, 0 destroy) while count_test[0] stayed untouched throughout; the next plan is empty; the G-ORACLE stock oracle on the same 2-instance count block, applied fresh in the idle greenfield-oracle account, shows the identical shape: destroy the higher index only (confirmed absent via describe-alarms), create it back (confirmed present again), the lower index untouched both times |
| Replace with create_before_destroy | pass | 5s | choudoufu: changing s3_requests_spike_renamed’s ForceNew alarm_name argument proposed exactly one replace at the same declared address (1 add, 0 change, 1 destroy; -/+ destroy and then create), applied cleanly; the old object (S3GetRequestsSpike) is confirmed gone and the new object (arn:aws:cloudwatch:us-west-2:000000000000:alarm:S3GetRequestsSpikeV2) 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 (S3GetRequestsSpike -> S3GetRequestsSpikeV2); 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 (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 | 9s | one argument edited (cf_requests_spike’s alarm_description, a config-owned non-ForceNew argument, gains a “(reviewed)” suffix), “plan -out=approved.tfplan” wrote a 7919-byte stock-format plan file whose whole change set is one update on module.monitoring.aws_cloudwatch_metric_alarm.cf_requests_spike; the world then moved out of band (S3GetRequestsSpike’s alarm_description, through the AWS CLI, 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 both module.monitoring.aws_cloudwatch_metric_alarm.s3_requests_spike and the live S3GetRequestsSpike it was computed against, with “Exit status 3” spelled out for a pipeline; nothing was applied - CFRequestsSpike’s alarm_description still read as configured through the AWS CLI, 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 description put back and nothing else changed, the IDENTICAL file applied - 0 added, 1 changed, 0 destroyed - and CFRequestsSpike read back with the reviewed description, so the refusal is earned by the drift and not handed out to every plan file. BOTH the plan -out and the apply carry this crossing’s own -target set (aws_budgets_budget stays out of the graph - floci still answers UnknownOperationException for AWSBudgetServiceGateway on the pinned image), which is enough because a live-markers apply plans the live system from its OWN arguments rather than replaying the file: no exemption and no Go change was needed for issue #903’s -target trap. 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 | 11s | 3 resources from nothing (2 tagged alarms + the untaggable dashboard), both alarm markers verified via the AWS CLI, 3 records in the local record store (#364 A2), replan empty, stock oracle in its own namespace matches structurally on both alarms |
| 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 1m29.6s.
Oracle: stock terraform 1.16.1, stock tofu 1.12.6 (matches the current pin).
FIVE OF FIVE, real, as of 2026-08-21 (crossing 77be0bc336 base). datapoints_to_alarm DELTA applied per lex00/floci#93’s own suggested workaround (explicit value = evaluation_periods on both alarms, AWS’s own create-time default, so nothing about what stage 1 creates changes) - verified for real, not assumed: the ‘1 -> null’ diff is gone from both stock tofu plan and choudoufu live-plan against the same live alarms. Getting stage 3’s automated assertion to actually SEE the empty plan uncovered a second, real, unrelated choudoufu bug: choudoufu live-plan’s delegation to plain choudoufu plan when a live block is present (plan.Run(originalArgs)) kept originalArgs as a second slice header over live-plan’s own rawArgs backing array rather than an independent copy, and arguments.ParseView’s in-place compaction of recognized flags (like -no-color) silently corrupted it whenever a flag followed -no-color - -target being the realistic case, since every -target/-exclude run hits this same alias. Effect: -no-color never reached the delegate, so live-plan’s output for every -target run (this estate included) carried real ANSI escape codes despite the flag, invisibly breaking any exact-string assertion like stage 3’s “No changes.” check - not a semantics bug (a manual rerun confirmed the plan was already empty before the fix), but the automated proof of it was blind. Fixed in internal/command/live_plan.go (originalArgs := append([]string(nil), rawArgs…)), regression-tested in internal/command/live_mode_test.go (confirmed to fail without the fix, pass with it). Stage 5 then hit a third, distinct, real bug - floci’s: CloudWatch PutMetricAlarm is documented (AWS CLI’s own bundled help) as create-only for tags, so a real out-of-band update can never touch existing tags; floci’s PutMetricAlarm wipes them instead, confirmed directly (list-tags-for-resource: two markers before, empty after an update with no –tags), destroying this crossing’s ownership marker. Filed as https://github.com/lex00/floci/issues/95. Worked around in this harness only (not floci, not a change to what stage 5 tests) by re-applying the known tags via TagResource immediately after each drift call. Re-crossed for real with all three fixes/workarounds in place: cold_deploy 3 resources added; migrate 2 of 3 stamped (dashboard correctly UNTAGGABLE), both tofu-address markers verified via the AWS CLI; test_plan genuinely EMPTY with both alarms’ markers and the dashboard’s re-derived identity re-verified after the state file was deleted; test_apply a genuine no-op, 2 objects before and after, no state file either time; drift_reconverge proposes fixing exactly the one drifted alarm, applies it, and the live value reads back correct. just ci green. BREAK=1 still verified failing at stage 2’s identity assertion (unchanged by this update - that check sits before stage 3 and exits the script before stage 5 is ever reached, a pre-existing property of the script’s control flow, not something this update touched).
EARLIER HISTORY. Landed 2026-08-21 (crossing 841d5dbdde base), the ninth OpenTofu-native estate: leynos/df12-www’s modules/monitoring, a real, actively-maintained personal-site deployment (241 commits, AGPL-3.0, dependabot-active) whose README opens “This repository contains the configuration for my static website deployment using OpenTofu” with no compatibility claim, and whose pinned tree is 34 .tofu files to exactly 1 .tf file (a Terraform test fixture outside this module). Scoped to modules/monitoring specifically: the one leaf module needing nothing else stood up first (bucket_name/distribution_id are free-form dimension strings, never looked up; no remote state, no data source). aws_budgets_budget targeted out of every stage - confirmed genuinely unimplemented by floci (absent from this pin’s floci-capabilities.json service list, absent from /_localstack/health, and a direct aws budgets create-budget call returns UnknownOperationException) - leaving the two aws_cloudwatch_metric_alarm resources and the one aws_cloudwatch_dashboard as the crossed set. cold_deploy: PASS for real, 3 resources added via -target (both alarms plus the dashboard), 0 pre-existing tofu-estate tags. UPDATE 2026-08-21 (re-pinned to sha256:d65baf42…, lex00/floci#88 fixed, build e61a987): migrate: PASS for real. live-import’s dry run verifies 2 of 3 eligible (the dashboard UNTAGGABLE, no tags argument in the provider’s schema); -approve stamps both alarms cleanly, and both tofu-address markers verify directly against CloudWatch through the AWS CLI, never through choudoufu’s own report. test_plan: was failing for real on a real, generalizable choudoufu parity defect, and no longer fails on it. internal/command/live_plan.go threaded args.Operation.Targets only into the final core tfCtx.Plan() call, while statelessResolve/statelessDataReads/statelessDiscover/statelessStamp walked the entire configs.Config regardless of -target and refused hard on the estate’s own aws_budgets_budget (‘Identity argument not set … module.monitoring.aws_budgets_budget.monthly_limit has no value for “account_id”, so its import identity (ACCOUNT_ID:NAME) cannot be built’), a resource scoped out by -target specifically because floci does not implement AWS Budgets. Verified NOT floci’s and NOT a normal admission gap before filing: a plain tofu plan with the identical -target set against the identical unmodified module succeeded cleanly (Plan: 3 to add, 0 to change, 0 to destroy) - stock prunes an untargeted resource out of the graph before ever evaluating it, HANDOFF.md label 2, ‘OpenTofu succeeds, choudoufu refuses’. Filed as https://github.com/INTENTIUS/choudoufu/issues/352 and FIXED there 2026-08-21: the stateless pipeline now reads which resource blocks survive -target/-exclude off the plan graph’s own TargetingTransformer, through a new tofu.Context.TargetedResources, and hands that scope to identity resolution and the data-read phase - so a block stock removed from the graph before evaluating it can no longer refuse the run, dependencies of a targeted resource stay in (the closure is the graph’s own, not a re-derivation), and an out-of-scope block that DOES resolve keeps its resolution so the marker sweep’s declared-address set stays complete. RE-CROSSED FOR REAL at the fix against the same pin (sha256:d65baf42…): that wall is gone - live-plan exits 0, resolves, discovers, stamps and renders a plan over the targeted set. test_plan is STILL ‘fail’, on a different wall one layer in and with a different label: both alarms render ‘- datapoints_to_alarm = 1 -> null’ for an argument this module’s config never sets, so the plan is not empty. Stock reproduces it identically - tofu plan in the stage-1 plain directory against the same live objects, no choudoufu in the process, proposes the same line for the same two alarms - and an ISOLATED minimal reproduction (one alarm, one directory, stock OpenTofu v1.12.5 + hashicorp/aws v5.100.0 against this same floci pin, no choudoufu at all) does not converge either: apply writes datapoints_to_alarm = 1 into state, floci’s DescribeAlarms returns no DatapointsToAlarm key at all, and every later plan wants to remove it. hashicorp/aws 6.x converges cleanly on the same image, so it is specific to the 5.x line this module’s own ‘~> 5.0’ constraint resolves to. HANDOFF.md label 1, ‘OpenTofu fails here too’ - PARITY, an emulator gap and not this fork’s defect. Filed as https://github.com/lex00/floci/issues/93. test_apply/drift_reconverge still not reached: test_plan’s own empty-plan assertion is what gates them. live/e2e/corpus-leynos-monitoring/run.sh’s header updated with both findings. BREAK=1 verified failing at stage 2’s identity assertion in an earlier real run (unaffected by this update - BREAK’s corrupted-marker check sits before stage 3).
Reproduce it#
go run ./tools/gauntlet run corpus-leynos-monitoringNeeds 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-leynos-monitoring/run.sh; BREAK=1 corrupts its assertions to show they are load-bearing.