3.6 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | ||
|---|---|---|---|---|---|---|
| resolved | 2026-10-01 |
|
mesh-controller PR 181 (every node's resolution read first, names attributed across them to the terminus, in order; the many shape of contributions counted) |
178 — A routed name resolves to a provider that was merely told it, and flips between plans
What was observed
From the home server, the dashboard's public name resolved inside the mesh to the control node, where no proxy serves it, and TLS failed; from outside it resolved to the home server and worked. Filed first in the forge's tracker on the hq repository (its issue 227), on 2026-09-30. The same night, two plans of the same machine taken a minute apart differed in exactly one resource — the mesh's names region — with the dashboard's name on one node's address and then on the other's.
A second thing hid behind it: no module that is routed under several names — the photo service's six, the invoicing service's two, the mail server's five — had any of them in the names region at all.
Why this is here
The names region is composed from every contribution the mesh gave a name to. A consumer that is routed contributes its label to its route, and the proxy serves the composed name. A consumer that also uses an identity provider contributes the same label there, because the provider must know the consumer's public name to compose a redirect — and by the rule that two readers must agree (issue 122) it is given the same composed name. So one name reaches two providers, and the code attributed it to the node of whichever contribution a map yielded last. Map order is not stable between runs; the region was not either.
The second fault is older: the single-value reading of a module's contributions is deliberately empty when the module contributes several times to one requirement (ADR 0094's sibling), and the names region used that reading, so a module with several routes named none.
Resolved, 2026-10-01
Every node's resolution is read first, and the names are attributed across them at once. The terminus serves the name: among the providers a name reaches, the one that is not itself published under a labelled name through another provider. An identity provider is routed through the proxy and so is a consumer of names, not their end; the proxy contributes no label to anyone and is. The rule knows nothing of what "route" means — it reads the graph the modules declared — and it walks nodes, requirements and contributions in order, so one mesh yields one region. Every shape of contribution is counted, so a module routed under several names has every one of them resolved.
How it is checked: the two-node mesh of the report, resolved and attributed twenty-five times — the dashboard's name on the home server, the identity provider's own name on the control node, no name leaked to the identity provider; a module with two routes yields two names; and, live, two plans of the home server after the roll-out identical in the names region, with the dashboard's name at the home server's address and the several-routed modules' names present.
Note on where this was filed
The symptom was filed in the forge's issue tracker, which is not where hq's issues live: a tracker issue carries no status the mesh's records read, and its numbers collide with hq's pull request numbers in conversation. It is closed there pointing here.