2026-09-05 10:27:11 +00:00
1 changed files with 51 additions and 0 deletions
@@ -0,0 +1,51 @@
+---
+status: resolved
+opened: 2026-08-31
+located-in: [mesh-control]
+fixed-by: mesh-control — something answered on this machine is still bound
+amended-design:
+---
+
+# 018 — A provider on the same machine was never announced to its consumer
+
+## Symptom
+
+A module that `binds` a provision receives a file naming where the provider is and what it said a
+consumer must know. When the provision turned out to be answered by another module **on the same
+machine**, no file was written at all.
+
+A build machine sharing a node with the registry it pushes to therefore started, connected to the
+broker, and looped: *cannot read what the mesh said about the artifact store: no such file or
+directory.*
+
+## Why this matters
+
+It was deliberate, and the reasoning is in the code: *a file saying "it is on this node" would be a
+fact nobody needs and one more thing to keep true.* That is **right about the location and wrong
+about everything beside it.** A binding also carries the provider's `serves` block — the port —
+and a consumer cannot invent that whether the provider is next door or on the same disk.
+
+**The failure names nothing.** Every part a person would check was correct: the module resolved,
+the machine applied it, the container ran, the credential was delivered and worked. The one file
+that did not exist was one the module never asked for by name — it asked for a *provision*, and
+the mesh silently decided the answer needed no writing down. The error is about a path, and the
+cause is a decision three layers away.
+
+**And it only appears when two modules land on one node**, which is the ordinary case in a small
+mesh and the rare case in a large one. It would have been found in production.
+
+## What was done
+
+The binding is written for a local provider too, **when the provider said something a consumer
+must know**. That keeps the original intent exactly where it was right: a shell is answered here
+and there is genuinely nothing to say about it; a registry is answered here and the port is still
+unguessable.
+
+The address is this machine's own name on the private network, or loopback when it has none — a
+machine off the network still reaches itself, and a name nothing resolves is worse than an address
+that always works.
+
+*Checked by resolving a node holding both a provider and its consumer and asserting the binding
+carries the port and the address; by the same on a machine with no private network, asserting
+loopback; and by the pre-existing check that a provision with nothing to say still writes nothing,
+which is the half that was right.*