Development record
the lock assertion in the grounds test is wall-clock so a loaded runner could pass it with no lock held
the lock assertion in the grounds test is wall-clock so a loaded runner could pass it with no lock held
Found by the round-3 adversarial ruthless review of build/itd-179.
The assertion is wall-clock: waited < 100ms against a 150ms hold. On the
reviewer's machine the unlocked mutant completed in 34ms, a ~3x margin, so a
sufficiently loaded runner could pass this test with no lock held at all.
It is NOT vacuous, and that distinction is the record: the reviewer proved the
guard independently via TestRecordGroundsConcurrentAppendsBothLand, which
loses entries deterministically without the lock. So the lock is genuinely
covered; this test is redundancy of a weaker kind sitting beside a
deterministic one.
Worth fixing when the file is next touched, because a timing assertion that can pass for the wrong reason is the seed of the mutation-vacuous class this workstream has now found four times.
Grounds
- pursued: we expect both lock tests to fail any writer that skips the mint lock, however slow; a no-lock mutant that passes either test would show it wrong
Frontmatter
| id | iss-2608301301041887 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | nitpick |
.abcd/work/issues/resolved/iss-2608301301041887-the-lock-assertion-in-the-grounds-test.md
open on GitHub ↗ · commit history ↗
mentions3
- iss-2609012020476120Four test sites now assert elapsed wall-clock time where they mean to assert behaviour: iss-2608292246210181 and iss-2608290810037763 in the scanner's adjacency tests, iss-2608301301041887 in the grounds lock test, and the bootstrap fresh-install self-check in internal/surface/cli. Each was found by a CI flake and each is being fixed site by site. Worth deciding whether the rule 'a test asserts behaviour or an operation count, never a duration' graduates to a principle under .abcd/development/principles/ or to a lint rule that refuses a time.Since comparison in a _test.go file, so the fifth site is refused at draft time rather than found by the next flake. This is a design decision and was not taken during autonomous-run-2026-09-01, where it was carried from the session handover; the fourth site was fixed on its own merits.
- iss-2609012020479351TestBootstrapFreshInstallSelfCheck in internal/surface/cli asserts wall-clock time: it wraps one exec of the provisioned binary answering version in a timer and fails when elapsed exceeds five seconds. It failed on the macOS CI leg after v0.7.0 merged (run 33496438371: 5.77s, 'want about a second') on a tree the merge-queue leg had just passed; locally the same test passes in about one second. The timer measures a single process spawn of an ~18MB freshly written executable, which on macOS carries first-run code-signature validation against a cold page cache, so the number is a property of the runner, not of the code. The test's own comment names the budget as loosened 'so a loaded CI box cannot fail a check about provisioning on a timing wobble', and it then did exactly that. Fourth site of the class recorded by iss-2608292246210181, iss-2608301301041887 and iss-2608290810037763; carried from the session handover into autonomous-run-2026-09-01. The fix must assert the behaviour the gate is about -- the provisioned binary answers version correctly, as the version report, with no Go on PATH -- and carry no duration at all.
- itd-179The reasoning behind what was pursued no longer evaporates at the gate — readiness and triage record grounds for the conjecture, not only the decision