From 63d328147e7dee7f049291a268ef6f0cd78a9011 Mon Sep 17 00:00:00 2001 From: jochen Date: Sun, 4 Oct 2026 01:29:32 +0200 Subject: [PATCH] Issues 215, 221 resolved with live proof; 222 diagnosed and resolved --- .../00-report.md | 8 +++++++- .../00-report.md | 8 +++++++- .../00-report.md | 20 +++++++++++++++++-- 3 files changed, 32 insertions(+), 4 deletions(-) diff --git a/04-ISSUES/215-a-module-built-at-a-commit-stops-following-its-branch/00-report.md b/04-ISSUES/215-a-module-built-at-a-commit-stops-following-its-branch/00-report.md index 4c70895..bb15219 100644 --- a/04-ISSUES/215-a-module-built-at-a-commit-stops-following-its-branch/00-report.md +++ b/04-ISSUES/215-a-module-built-at-a-commit-stops-following-its-branch/00-report.md @@ -1,5 +1,5 @@ --- -status: located +status: resolved opened: 2026-10-03 located-in: - mesh-controller @@ -34,3 +34,9 @@ Owner mesh-controller. **Fix direction:** a build asked at a commit does not cha module follows; or, if pinning is meant, the pin is said — in `module list`, in `status`, and by a merge's plan naming the module it leaves out and why. A test: building a module at a commit and then merging a change to it plans it. + +## Resolved + +Proven 2026-10-04: the catalogue merges since the fix rebuilt the module that had been pinned at an +old commit, at the merge's commit, by an ordinary plan — the same as every other module of the +catalogue. Nothing was asked for it by hand. diff --git a/04-ISSUES/221-a-build-machine-learns-a-new-builder-only-from-a-push/00-report.md b/04-ISSUES/221-a-build-machine-learns-a-new-builder-only-from-a-push/00-report.md index 319371f..7f6c0d1 100644 --- a/04-ISSUES/221-a-build-machine-learns-a-new-builder-only-from-a-push/00-report.md +++ b/04-ISSUES/221-a-build-machine-learns-a-new-builder-only-from-a-push/00-report.md @@ -1,5 +1,5 @@ --- -status: located +status: resolved opened: 2026-10-04 located-in: - mesh-controller @@ -44,3 +44,9 @@ stopping at the first failure. **How it is checked:** the next controller merge' build agent to the build machines before its last tier, and a build asked right after the plan finishes runs the new builder; then this moves to resolved. Whether the other modules roll out is the operator's policy, not this issue's. + +## Resolved + +Proven 2026-10-04: the next controller merge's plan logged that its first tier was built and the +build agent sent to all four build machines, and only then asked its next tier. The builder change +in that merge reached the build machines without a hand push. diff --git a/04-ISSUES/222-an-assignment-is-refused-on-the-bus-until-the-bus-machine-is-pushed/00-report.md b/04-ISSUES/222-an-assignment-is-refused-on-the-bus-until-the-bus-machine-is-pushed/00-report.md index e3f9d83..63ee86d 100644 --- a/04-ISSUES/222-an-assignment-is-refused-on-the-bus-until-the-bus-machine-is-pushed/00-report.md +++ b/04-ISSUES/222-an-assignment-is-refused-on-the-bus-until-the-bus-machine-is-pushed/00-report.md @@ -1,8 +1,10 @@ --- -status: open +status: resolved opened: 2026-10-04 -located-in: [] +located-in: + - mesh-tools fixed-by: + - mesh-tools#47 amended-design: --- @@ -33,3 +35,17 @@ tells the operator to run, leaves the module running and unreachable, with nothi Whether a push to one machine should also send the bus's machine when the user list it would compose differs from the one that machine holds. **How it is checked:** assign a module with tools to a machine that does not run the bus, push only that machine, and its tools answer. + +## Diagnosed and resolved + +The push did send the bus's machine: the controller's log shows both machines applying in the same +second. The fault was the order within that second. The node's runtime subscribed before the bus +had reloaded its user list, the bus refused, and the bus client marks a refused subscription dead. +Nothing asked again until a later membership happened to re-serve the module. + +A subject the runtime answers on is now asked for again when the bus refuses it, after waits from +two seconds to two minutes, and given up and said after about five minutes. **How it is checked:** +a test refuses a subject and finds it asked for again and answering, given up past its attempts, +and not asked again once stopped; and by hand against a bus whose permissions were reloaded while +connected, the runtime answered two seconds after the grant arrived, where the runtime before the +fix never answered. -- 2.54.0