Hand a mesh of one its store by loopback until a resolver answers its name (issue 701) #325
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: novox/mesh-controller#325
Reference in New Issue
Block a user
What
artifactStoreAddressanswers127.0.0.1:<port>instead of<node>.internal:<port>in exactly one case: the store's own node asks, it is the only node on the private network, and no node holds the mesh's resolver seatmesh-dns-resolver(meshNamesAnswered, which reads the same holders a machine's resolver file lists). Every other case is unchanged:Why
In run-2026-10-14T05-52-08-387Z, genesis placed anchor on the private network at step 21. From then on every reference the mesh composed named the store
anchor.internal:5000. Nothing answers that name until a module holdsmesh-dns-resolver(ADR 0194), and genesis installs none. So the filter's build at step 22 randocker run anchor.internal:5000/mesh-tools/build@…and the runtime answeredlookup anchor.internal: no such host. The registry trust foranchor.internal:5000was in place; the name simply had no answer.Design limit
I chose this on my own; the triage marked the issue as needing a decision. Loopback applies only to a mesh of one: there loopback is the truth for every caller, and it is what genesis already used before the network. I did not pick the other two ways:
The live mesh has
mesh-dns-resolverheld by dnsmasq on ace and novox, and four nodes on the network, so nothing it composes changes.Tested
TestAMeshOfOneIsHandedNoNameUntilAResolverAnswersIt(store test, listed in testdata/store-tests):127.0.0.1:5101, and so does a base handed to the builder;anchor.internal:5101.anchor.internal:5101.TestTheRegistryTrustAndEveryImageFollowThePortTheNodeGaveTheStore) still gets the internal name everywhere../cmd/mesh-controllerpackage passes against a throwaway postgres 17 (172 s), andgo vetis clean.Fixes issue 701.
Delivery
novox/mesh-controller@0350b4e22276— proposed since 2026-10-14T13:22:26ZDelivery plan — builds mesh-controller → novox; no bus step
Transitions
535c7641ac, the trunk is now c975dbf7b053; judged again on a recheck or when it is mergedThe commit's note under
refs/notes/mesh-plankeeps every transition:git log --notes=mesh-plan.Merge check at
eb992848Judged: head
eb99284890ccmerged into trunk3479a35462b2; read beside it: mesh-cataloga44d490d974c, mesh-controller-main3479a35462b2, mesh-host1a2677882380, mesh-tools954e1a53eef9mesh/merge-gate: PASS — every machine composes with the change as it did without (4 of 4 compose) (modules: mesh-controller)mesh/repo-check: PASS — its merge-check.sh passedDelivery plan — builds mesh-controller → novox; no bus step
Run by the build seat on ace as
build-1791959576609542553(builds --log build-1791959576609542553).Merge check at
d53fea31Judged: head
d53fea31f0afmerged into trunk3479a35462b2; read beside it: mesh-cataloga44d490d974c, mesh-controller-main3479a35462b2, mesh-host1a2677882380, mesh-tools954e1a53eef9mesh/merge-gate: PASS — every machine composes with the change as it did without (4 of 4 compose) (modules: mesh-controller)mesh/repo-check: PASS — its merge-check.sh passedDelivery plan — builds mesh-controller → novox; no bus step
Run by the build seat on novox as
build-1791961086127996425(builds --log build-1791961086127996425).Second commit
d53fea31. With only the first commit (eb992848), run-2026-10-14T06-32-20-126Z got past the base pull at step 22. It then failed publishing:cannot reach the registry at anchor.internal:5000 ... lookup anchor.internal on 1.1.1.1:53: no such host. The build agent'sMESH_REGISTRYis its same-node binding${bound:artifact-store:at}, and that binding was composed from the node's own internal name.The second commit composes a lone node without its own name while no resolver holds
mesh-dns-resolver. Same-node bindings then fall back to loopback, exactly as before the network. A node's own name feeds only same-node bindings,${machine:at}/${machine:address}(used by dnsmasq, which is itself the resolver, and step-ca) and route names. The test now also checks the builder's composedMESH_REGISTRY:127.0.0.1:5101without a resolver,anchor.internal:5101with one. Without plan.go's change it fails.Lab run-2026-10-14T06-58-04-985Z on shanks, genesis-keeps-its-bus with mesh-controller
d53fea31and everything else on main: the second genesis ran all 24 steps ("The installer finished"; "this machine is a mesh of one node: it builds its own software, holds its graph, sits on its private network, and filters what modules declared"). Bed verdict: 1 passed, "one bus, mesh-broker-nats, on the module's image; 8 stream(s) kept; anchor connected".Merge check at
d53fea31Judged: head
d53fea31f0afmerged into trunk04730b54a8f2; read beside it: mesh-cataloga44d490d974c, mesh-controller-main04730b54a8f2, mesh-host1a2677882380, mesh-tools954e1a53eef9mesh/merge-gate: PASS — every machine composes with the change as it did without (4 of 4 compose) (modules: mesh-controller)mesh/repo-check: PASS — its merge-check.sh passedDelivery plan — builds mesh-controller → novox; no bus step
Run by the build seat on shanks as
build-1791962605814281759(builds --log build-1791962605814281759).Verdict: changes needed at
d53fea31f0(one small one): the fix is right for genesis, but aLoneNameNothingAnswers is not exact. A degraded read of the live mesh can make it true for g14 or shanks.Independent review for issue 701 (a lone node is handed a name nothing answers).
Checks at this head, fresh, judged against trunk
04730b54a8at 07:29: mesh/merge-gate success ("PASS — every machine composes with the change as it did without (4 of 4 compose) (modules: mesh-controller)"), mesh/repo-check success ("PASS — its merge-check.sh passed"; the store tests include "--- PASS: TestAMeshOfOneIsHandedNoNameUntilAResolverAnswersIt (0.35s)"), mesh/delivery success ("ready: waits for its merge"). No mesh/delivery-group status. The gate composing all four machines unchanged shows the live mesh, read as it is now, does not take the path.if err != nil || len(assigned) == 0 { continue }), and drops, saying it on stderr only, a machine whose modules do not resolve against the catalogue (issue 188's case). If ace, novox and one other drop out of one reading, the one left sees itself alone, and no holder survives the address filter. ace and novox can never be that one, since each holds a resolver itself. But g14 or shanks would then be planned with At = "": composed as off the network for that send, its same-node bindings by loopback. It is a degraded state already, but this adds a wrong composition pushed during it, not just a missing name. Today's code would still hand that node its own name.The lab run named (run-2026-10-14T06-58-04-985Z on shanks, all 24 genesis steps) I did not re-read; I take it as reported.
Reviewed by an independent reviewer on g14.
Merge check at
0350b4e2Judged: head
0350b4e22276merged into trunk535c7641ac41; read beside it: mesh-cataloga44d490d974c, mesh-controller-main535c7641ac41, mesh-host1a2677882380, mesh-tools954e1a53eef9mesh/merge-gate: PASS — every machine composes with the change as it did without (4 of 4 compose) (modules: mesh-controller)mesh/repo-check: PASS — its merge-check.sh passedDelivery plan — builds mesh-controller → novox; no bus step
Run by the build seat on novox as
build-1791968846335814482(builds --log build-1791968846335814482).View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.