Issue 018: a provider on the same machine was never announced to its consumer

2026-08-31 01:35:54 +02:00
parent 00e98f1f92
commit 8448219de1
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.*