2.5 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | |
|---|---|---|---|---|---|
| resolved | 2026-08-31 |
|
mesh-control — something answered on this machine is still bound |
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.