Register R349: a merge acted on late superseded the merge after it (hq issue 349) #95
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: novox/mesh-lab#95
Reference in New Issue
Block a user
What. An R349 entry in
replays/register.go, after R340:TestReplay349in mesh-controller, Fix = 9ca7952d (the merge of mesh-controller #179), Home = mesh-controller f796dc0b (mesh-controller #290, the replay's commit, reachable once it merges).Why. Issue 349 is a core issue and resolves with a replay (ADR 0237). On 2026-10-09 a catalogue merge handed over late superseded the plan of the merge made after it and planned the fixed module again at the commit without the fix.
How it was tested.
go run ./cmd/prove R349against a throwaway postgres 17 (removed after):R349 (issue 349): PROVED — before its fix fails, on its fix passes. It also passes on mesh-controller main.TestEveryReplayIsWholeandgo vetpass.For issue 349. Pairs with mesh-controller #290 (same branch name); merge that one first.
Delivery
novox/mesh-lab@d16c3db9d2d0— delivered since 2026-10-13T03:54:47ZDelivery plan — builds nothing: the change touches no module of the mesh's graph
Group
fix/349-replay, in order: novox/mesh-controller@5740874ce3 → novox/mesh-lab@d16c3db9d2Transitions
The commit's note under
refs/notes/mesh-plankeeps every transition:git log --notes=mesh-plan.Verdict: approve at
39ec294853The entry is placed correctly: replays/register.go gains exactly one new entry, right after R340 ("1 file changed, 16 insertions(+)" against main
6ba65a1), and nothing else in the file changes.Its fields check out: Fix = "9ca7952d5e0a5ed1e23bdcf5aea36fe967e62d14" is exactly mesh-controller #179's merge commit, and Home = "mesh-controller", HomeRef = "f796dc0b73075be13fefe80fe10d556ec9fa899e" is exactly mesh-controller #290's head.
I ran
go run ./cmd/prove R349from mesh-lab's replays/ directory (its default --repos, ../.., resolved to the directory holding the mesh-controller clone) against the throwaway postgres 17. Output: "R349 (issue 349): PROVED -- before its fix fails, on its fix passes", with the "before" line quoting "plan-... building at 8ff8197a: app notes" -- matching the PR's own report verbatim.go vet ./...is clean on this head, and TestEveryReplayIsWhole passes ("--- PASS: TestEveryReplayIsWhole").One caveat, not a blocker here: my review of the companion mesh-controller #290 found that TestReplay349's "passes on main" result is weaker evidence than it looks once ADR 0276's batches are accounted for -- the queued plan for the second merge is never actually cut within that test, so main's real resolution of the differing-module case is not exercised by it. That is a defect in the replay itself, not in this registration: everything this PR states about Fix, Home and the
go run ./cmd/proveoutcome is accurate, so it stands on its own merits. It should just not be read, on its own, as independent confirmation that main is proven safe beyond what #290 itself demonstrates.Verdict: approve at
d16c3db9d2The only change from the previous head is HomeRef, updated from f796dc0b to 5740874c -- exactly mesh-controller #290's new head after it was revised for my earlier request-changes review. Fix (9ca7952d5e0a5ed1e23bdcf5aea36fe967e62d14) and placement (after R340) are unchanged and still correct.
I ran
go run ./cmd/prove R349from mesh-lab's replays/ directory against the throwaway postgres 17. Output: "R349 (issue 349): PROVED — before its fix fails, on its fix passes", with the "before" line quoting "plan-... building at c1other: other" -- the new test's third (own-repository) merge, confirming the updated replay file is what ran.go vet ./...is clean and TestEveryReplayIsWhole passes ("--- PASS: TestEveryReplayIsWhole").The caveat from my previous review of this PR is resolved: mesh-controller #290's replay now actually drives main's batch cut and fails on an empty plan rather than skipping it, so this registration's claim is no longer resting on a weaker demonstration than it states.