From 33b0ee3d538a47c6a9ad90bded9277f88a4d7019 Mon Sep 17 00:00:00 2001 From: jochen Date: Thu, 8 Oct 2026 17:02:52 +0200 Subject: [PATCH] Issue 331: state how the fix is proved, what CI still skips, and that the grants hold live --- .../00-report.md | 14 +++++++++++--- .../01-diagnosis.md | 14 ++++++++++---- 2 files changed, 21 insertions(+), 7 deletions(-) diff --git a/04-ISSUES/331-a-declared-tool-check-is-never-asked-on-the-live-link/00-report.md b/04-ISSUES/331-a-declared-tool-check-is-never-asked-on-the-live-link/00-report.md index bf35af53..86b8aca6 100644 --- a/04-ISSUES/331-a-declared-tool-check-is-never-asked-on-the-live-link/00-report.md +++ b/04-ISSUES/331-a-declared-tool-check-is-never-asked-on-the-live-link/00-report.md @@ -42,9 +42,17 @@ The diagnosis is in [01-diagnosis.md](01-diagnosis.md). ## How it is checked -- **In the node-engine's tests:** a queue attached to the NATS link the engine dials must reach that - link's `Ask`; it fails on the commit before the fix with "the NATS link was not asked". A second test, - run against a real bus (`MESH_TEST_NATS`), asks a served tool through the queue and reads it healthy. +- **In the node-engine's tests, with no bus:** a queue attached to the NATS link the engine dials must + reach that link's `Ask`, and a link that cannot ask is said apart from no link. On the commit before + the fix it fails at its second step, with "on a link that cannot ask: no link to the bus is open": + the queue said the same words for both. +- **In the node-engine's tests, on a real bus** (`MESH_TEST_NATS`): a served tool is asked through the + queue and read healthy, and a tool nothing serves is said as such. **The pull request's repository + check skips this test today**: the build seat's Go toolchain holds no nats-server, so nothing sets + `MESH_TEST_NATS` there. The node-engine's `merge-check.sh` now starts a throwaway nats-server and runs + these tests whenever the toolchain holds one, and prints "NOT RUN AGAINST A BUS" when it does not. It + passed so locally. **Open:** the Go toolchain image does not carry a nats-server yet, so in the build + seat the real-bus tests remain skipped and say so. - **At build time:** the NATS link is asserted to satisfy every optional interface the queue asks of it (health, tool, key reading, being asked to report), so a link that drops one does not build. - **Live:** after the fix reaches the laptop, `mesh-controller.conditions` no longer holds the sensors diff --git a/04-ISSUES/331-a-declared-tool-check-is-never-asked-on-the-live-link/01-diagnosis.md b/04-ISSUES/331-a-declared-tool-check-is-never-asked-on-the-live-link/01-diagnosis.md index ea20e21f..9980322e 100644 --- a/04-ISSUES/331-a-declared-tool-check-is-never-asked-on-the-live-link/01-diagnosis.md +++ b/04-ISSUES/331-a-declared-tool-check-is-never-asked-on-the-live-link/01-diagnosis.md @@ -22,9 +22,12 @@ attached the NATS link and asked a tool through the queue. **Ruled out.** - *The bus grant.* The controller composes a machine's grant for each declared check as - `mesh.mod..tool..` (internal/broker, CheckSubjects), and the NATS link's - inbox is granted for its other questions (the witness's `Ping`). The question never reached the bus, - so the grant was never tried. + `mesh.mod..tool..` (internal/broker, CheckSubjects). **Verified live** on + 2026-10-08 with `nats.nats_users`: the laptop's node-engine user may publish + `mesh.mod.sensors.tool.sensors_health.` and subscribe to its own inbox, and the laptop's tool + runner subscribes to `mesh.mod.sensors.tool.>` and may respond. Calling `sensors_health` on the laptop + through the mesh MCP server answered healthy. The question never reached the bus, so the grant was + never tried. - *The tool runner.* The same module's tools answered through the mesh MCP server. - *A link opened late and never retried.* The queue re-reads the link on every look, and the condition counted 296 failed looks in a row over five hours with the link up. @@ -35,4 +38,7 @@ Any module that declares a tool check is affected in the same way. **Fix.** Pull request 57 on `novox/mesh-host`: `natsLink.Ask`, through `OverNATS.Ask`, naming "nothing on this machine answers" for no responders and a refused grant the way `Ping` does; build-time assertions of -the NATS link's interfaces; and distinct words for a link that cannot ask. +the NATS link's interfaces; and distinct words for a link that cannot ask. The same pull request says a +check's error once (the evidence read "asking it: asking …"), says a deadline as "no answer within" the +time the check gave it, and names a refusal only when the bus refused this question: the client keeps its +last error for the life of the connection, so a refusal under a grant since widened was said again.