Register R348: a fault from before a send failed the builds sent after it (hq issue 348) #96

2026-10-13T04:10:03Z

mesh-admin commented

2026-10-13 04:10:03 +00:00

What: R348 in replays/register.go, an InRepository replay in mesh-controller: Fix 9ca7952d (mesh-controller #179), test TestReplay348AFaultFromBeforeTheSendFailsNoGate, file cmd/mesh-controller/replay348_test.go, Home mesh-controller at 6eea92c3 (the commit of the controller PR that adds it; reachable once that merges).

Why: issue 348 is a core issue and resolves with its replay (ADR 0237). The resolver's half (mesh-catalog #161, 105cc7c0) has no replay here: the dnsmasq module had no Go before that fix, and the binding's loss was never reproduced past the teardown burst that caused it (the issue's diagnosis); dnsmasq's own tests and the controller's manifest test hold it. The entry says so.

How it was tested: go run ./cmd/prove --repos <clones> R348 with MESH_TEST_POSTGRES: PROVED, fails before its fix, passes on it. sh replays/merge-check.sh: ok.

Fixes issue 348 (its replay).

What: R348 in replays/register.go, an InRepository replay in mesh-controller: Fix 9ca7952d (mesh-controller #179), test TestReplay348AFaultFromBeforeTheSendFailsNoGate, file cmd/mesh-controller/replay348_test.go, Home mesh-controller at 6eea92c3 (the commit of the controller PR that adds it; reachable once that merges). Why: issue 348 is a core issue and resolves with its replay (ADR 0237). The resolver's half (mesh-catalog #161, 105cc7c0) has no replay here: the dnsmasq module had no Go before that fix, and the binding's loss was never reproduced past the teardown burst that caused it (the issue's diagnosis); dnsmasq's own tests and the controller's manifest test hold it. The entry says so. How it was tested: `go run ./cmd/prove --repos <clones> R348` with MESH_TEST_POSTGRES: PROVED, fails before its fix, passes on it. `sh replays/merge-check.sh`: ok. Fixes issue 348 (its replay).

mesh-admin added 1 commit 2026-10-13 04:10:04 +00:00

Register R348: a fault from before a send failed the builds sent after it (hq issue 348)

mesh/merge-gate head becff66e0a8a merged into trunk 2aebf8f40e25 — pass: the change touches no module of the mesh's graph

Details

mesh/repo-check head becff66e0a8a merged into trunk 2aebf8f40e25 — pass: its merge-check.sh passed, each part in its toolchain: merge-check.sh (typescript)…

Details

mesh/delivery delivered

Details

mesh/delivery-group group fix/348-replay delivered: every member is delivered

Details

becff66e0a

Proved with replays/cmd/prove: it fails on mesh-controller #179's first parent
and passes on the fix. The resolver's half (mesh-catalog #161) has no replay:
the module had no Go before it, and the binding's loss never reproduced past
its burst; the entry says so.

mesh-admin commented

2026-10-13 04:10:18 +00:00

Delivery novox/mesh-lab@becff66e0a8a — delivered since 2026-10-13T04:40:09Z

Delivery plan — builds nothing: the change touches no module of the mesh's graph

Group fix/348-replay, in order: novox/mesh-controller@6eea92c323 → novox/mesh-lab@becff66e0a

composed together: pass — the change touches no module of the mesh's graph

Transitions

2026-10-13 04:10 (new) → proposed (announced): novox/mesh-lab#96's head announced
2026-10-13 04:14 proposed → checked (checked): a verdict names this commit and the trunk's head as its trunk commit
2026-10-13 04:14 checked → ready (accepted): the gate passed or warned, and the repository's own check did not fail
2026-10-13 04:40 ready → published (merged): on the trunk its modules follow: merged there, and its walk opened — or nothing for a walk to move
2026-10-13 04:40 published → delivered (done): nothing for a walk to move

The commit's note under refs/notes/mesh-plan keeps every transition: git log --notes=mesh-plan.

**Delivery** `novox/mesh-lab@becff66e0a8a` — **delivered** since 2026-10-13T04:40:09Z **Delivery plan** — builds nothing: the change touches no module of the mesh's graph **Group** `fix/348-replay`, in order: novox/mesh-controller@6eea92c323f4 → novox/mesh-lab@becff66e0a8a - composed together: pass — the change touches no module of the mesh's graph **Transitions** - 2026-10-13 04:10 (new) → proposed (announced): novox/mesh-lab#96's head announced - 2026-10-13 04:14 proposed → checked (checked): a verdict names this commit and the trunk's head as its trunk commit - 2026-10-13 04:14 checked → ready (accepted): the gate passed or warned, and the repository's own check did not fail - 2026-10-13 04:40 ready → published (merged): on the trunk its modules follow: merged there, and its walk opened — or nothing for a walk to move - 2026-10-13 04:40 published → delivered (done): nothing for a walk to move The commit's note under `refs/notes/mesh-plan` keeps every transition: `git log --notes=mesh-plan`.

mesh-admin reviewed

2026-10-13 04:26:04 +00:00

mesh-admin left a comment

Verdict: approve at becff66e0a

R348's Fix (9ca7952d5e0a5ed1e23bdcf5aea36fe967e62d14) and HomeRef (6eea92c323f4862d4162f9d977c8783d8a62efc3) match mesh-controller #179's merge and #291's head exactly.

I ran go run ./cmd/prove --repos R348 from replays/ with MESH_TEST_POSTGRES pointing at a throwaway postgres:17-alpine container, against clones of mesh-controller (full history, including 9ca7952d and its parent). Output: "R348 (issue 348): PROVED — before its fix fails, on its fix passes", with the before failure quoting "the restarted node-engine's first, undecided statement cleared the network condition while the resolver still refused" — the same bug issue 348 describes. sh replays/merge-check.sh also ran clean.

The note on why the resolver half has no replay is sound. I checked mesh-catalog's history directly: before 2b2397a (part of #161), modules/dnsmasq held only client.ts/index.ts/tools/index.ts — no Go at all — so there is no pre-fix Go test harness this kind of replay (InRepository, laid over a worktree and run with go test) could be laid over. I also read the issue's diagnosis (04-ISSUES/348.../01-diagnosis.md): the bind-dynamic closing was reproduced only as brief listener closings inside a teardown burst, always re-bound within the same burst (0 of 180 trials stayed unbound two seconds later); the actual 20-minute persistent loss was never reproduced and its cause ("the netlink socket overflowing … or no address changing for twenty minutes") is explicitly marked "Guessed", not measured. So "the binding's loss never reproduced past its burst" is an accurate characterization, and relying on dnsmasq's own tests plus the controller's manifest test (bind-interfaces required, bind-dynamic refused) for that half is reasonable given no deterministic repro exists.

Verdict: approve at becff66e0a8a9f4a1b8d9d3654f0b6ed5ea5c077 R348's Fix (9ca7952d5e0a5ed1e23bdcf5aea36fe967e62d14) and HomeRef (6eea92c323f4862d4162f9d977c8783d8a62efc3) match mesh-controller #179's merge and #291's head exactly. I ran go run ./cmd/prove --repos <clones> R348 from replays/ with MESH_TEST_POSTGRES pointing at a throwaway postgres:17-alpine container, against clones of mesh-controller (full history, including 9ca7952d and its parent). Output: "R348 (issue 348): PROVED — before its fix fails, on its fix passes", with the before failure quoting "the restarted node-engine's first, undecided statement cleared the network condition while the resolver still refused" — the same bug issue 348 describes. sh replays/merge-check.sh also ran clean. The note on why the resolver half has no replay is sound. I checked mesh-catalog's history directly: before 2b2397a (part of #161), modules/dnsmasq held only client.ts/index.ts/tools/index.ts — no Go at all — so there is no pre-fix Go test harness this kind of replay (InRepository, laid over a worktree and run with go test) could be laid over. I also read the issue's diagnosis (04-ISSUES/348.../01-diagnosis.md): the bind-dynamic closing was reproduced only as brief listener closings inside a teardown burst, always re-bound within the same burst (0 of 180 trials stayed unbound two seconds later); the actual 20-minute persistent loss was never reproduced and its cause ("the netlink socket overflowing … or no address changing for twenty minutes") is explicitly marked "Guessed", not measured. So "the binding's loss never reproduced past its burst" is an accurate characterization, and relying on dnsmasq's own tests plus the controller's manifest test (bind-interfaces required, bind-dynamic refused) for that half is reasonable given no deterministic repro exists.

mesh-admin merged commit 73800225c3 into main

2026-10-13 04:39:44 +00:00

mesh-admin deleted branch fix/348-replay

2026-10-13 04:39:44 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-lab#96