4.1 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | ||
|---|---|---|---|---|---|---|
| resolved | 2026-09-22 |
|
mesh-host#21, mesh-controller#45, mesh-catalog#39 |
085 — The packages port given at genesis is not a setting, and a later module can undo it
What was observed
Found while fixing review findings in the build of adoption mode (ADR 0100), by reading code rather than by running it.
Genesis can now be given the foundation's ports, so that a mesh raised beside a predecessor does not bind a port the predecessor holds. For the store, the bus, the broker's management port and the registry, the port given becomes a per-node setting of the module that serves it. Every reader then follows it: the module's container, the filter, the guard and the addresses consumers are told.
The package registry's port is the exception. The package registry runs as a bootstrap forge during genesis, and the builder reaches it through a binding whose port is written into the builder's manifest. The installer fixes the given port into that one manifest by rewriting its text when it registers the builder. So:
- a later registration of the builder from the catalogue puts the manifest's own port back;
- when the forge's own module takes the bootstrap forge over, the forge is configured with the catalogue's port, not the one given, and so is the address it tells others.
On a control-node where the predecessor's forge holds the default port, either one points the builder, and its registry credential, at the predecessor's forge.
Why it matters beyond this instance
"The foundation's ports are the node's" (ADR 0100) holds only where the port is a setting of the module that serves it. A port fixed by rewriting text at genesis holds only until something registers or takes over that module again, and nothing checks that it stays given.
Open questions
- Should the forge's module carry the packages port as its own node setting, the way the store does, so that the builder's binding is resolved from what the forge serves rather than written in the builder's manifest?
- Should a binding in a manifest ever name a port, or only what it needs, with the port resolved from the provider?
- What should check that every foundation port given at genesis is still the port in use after the foundation is adopted as modules?
Resolution
2026-09-22. The port given at genesis is a per-node setting now, in two places: the forge's own
ports, and the serves.port of the binding the builder carries. Both come from the one input at
genesis. The installer no longer rewrites the builder's manifest, so re-registering the builder
keeps the port, and the forge's module comes up on it.
The forge's module is registered at genesis without being assigned, so the setting has something to hang on — which also has the controller reserve that machine port, something it could not do before because it did not know the bootstrap forge existed.
On a default-port genesis none of that happens. The recording is skipped when the port is the catalogue's own, so the ordinary mesh raises a forge the controller has never heard of, holding a port the controller has not reserved. Noticed while surveying this ground on 2026-09-23 (research 013).
Open question 2 of this report is not answered: a binding still names a port rather than resolving it from the provider. Answering it needs a requirement that may go unanswered during genesis, and the mesh has no such thing. Open question 3 is not answered either: nothing checks that a port given at genesis is still the port in use once the foundation is adopted as modules.
Three neighbouring gaps found on the way are their own reports: 088, 089, 090.