From a2c9fbb665deb7a487d65f7f9e1b125029feff46 Mon Sep 17 00:00:00 2001 From: jochen Date: Thu, 1 Oct 2026 20:54:10 +0200 Subject: [PATCH] Issues 184 and 188 resolved: the merge handler returns at once; a machine is resolved with its pins and a dropped one is said --- .../00-report.md | 15 +++++++++++++-- .../00-report.md | 12 ++++++++++-- 2 files changed, 23 insertions(+), 4 deletions(-) diff --git a/04-ISSUES/184-a-merge-announcement-blocks-the-controllers-receive-loop/00-report.md b/04-ISSUES/184-a-merge-announcement-blocks-the-controllers-receive-loop/00-report.md index c6bd562..d54f706 100644 --- a/04-ISSUES/184-a-merge-announcement-blocks-the-controllers-receive-loop/00-report.md +++ b/04-ISSUES/184-a-merge-announcement-blocks-the-controllers-receive-loop/00-report.md @@ -1,8 +1,8 @@ --- -status: located +status: resolved opened: 2026-10-01 located-in: [mesh-controller cmd/mesh-controller/upgrades.go (the merge handler builds inside the receive loop)] -fixed-by: +fixed-by: mesh-controller PR 197 (ADR 0162: the merge handler writes a plan, asks the first tier and returns; outcomes and a ticker advance it) and PR 199 amended-design: [] --- @@ -56,3 +56,14 @@ interleaved with the merge's own. [ADR 0162](../../02-DECISIONS/0162-a-merge-produces-a-tiered-plan-the-mesh-keeps.md): a merge produces a tiered plan the store keeps; the handler asks the first tier and returns; outcomes advance the plan; a controller replaced mid-plan resumes it. The loop is never held by a build again. + +## Resolved, 2026-10-01 evening + +Since the controller holding ADR 0162's plan rolled, a merge announcement is handled in +milliseconds: the plan is written, the first tier asked, the loop free. The builds the merge +implies are asked from the store's record, tier by tier, so a controller replaced mid-plan resumes +it rather than losing it. The first live merge under it (a controller change) is the proof the +decision's table asks for; its tiers are read with `plans`. + +*How it is checked:* the plan tests in mesh-controller; live, `plans` after a merge and the loop's +log taking reports in while the plan builds. diff --git a/04-ISSUES/188-a-refusal-inside-on-the-network-drops-a-machine-silently/00-report.md b/04-ISSUES/188-a-refusal-inside-on-the-network-drops-a-machine-silently/00-report.md index 1f6cc1d..80fa610 100644 --- a/04-ISSUES/188-a-refusal-inside-on-the-network-drops-a-machine-silently/00-report.md +++ b/04-ISSUES/188-a-refusal-inside-on-the-network-drops-a-machine-silently/00-report.md @@ -1,8 +1,8 @@ --- -status: located +status: resolved opened: 2026-10-01 located-in: [mesh-controller cmd/mesh-controller/plan.go (theRestOfTheMesh resolves every other machine without its pins and skips one that refuses, saying nothing), mesh-controller cmd/mesh-controller/network.go (onTheNetwork, the same)] -fixed-by: +fixed-by: mesh-controller PR 199 (each machine resolved with its own pins; a dropped machine said in both passes), rolled 2026-10-01 evening; PR 200 keeps the per-machine view quiet amended-design: [] --- @@ -53,3 +53,11 @@ Found by a diagnostic build counting what each machine yielded. Fixed by mesh-co `fix/a-machine-not-on-the-network-is-said`: each machine is resolved with its own pins, and a machine left out is named with the resolver's words in both places. The pin itself (`step-ca`, the issuer the proxy already had) was made by hand and stands. + +## Resolved, 2026-10-01 evening + +The controller holding the fix was rolled onto the control node by the operator and a colleague +(the running one could not roll itself); after it every seat read as held again, a build asked +through the git seat worked, all four machines resolved and pushed. The line naming a dropped +machine spoke once too often — in the per-machine view, where the others are resolved without the +planned machine's offers and may fail by design — and is quiet there since mesh-controller PR 200. -- 2.54.0