Issue 331: state how the fix is proved, what CI still skips, and that the grants hold live

2026-10-08 17:02:52 +02:00
parent 08e065fbb6
commit 33b0ee3d53
2 changed files with 21 additions and 7 deletions
@@ -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
@@ -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.<module>.tool.<tool>.<machine>` (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.<module>.tool.<tool>.<machine>` (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.<machine>` 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.