77 lines
4.1 KiB
Markdown
77 lines
4.1 KiB
Markdown
---
|
|
status: resolved
|
|
opened: 2026-09-22
|
|
located-in: [mesh-host internal/bootstrap, mesh-catalog modules/builder]
|
|
fixed-by: mesh-host#21, mesh-controller#45, mesh-catalog#39
|
|
amended-design:
|
|
---
|
|
|
|
# 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](../../02-DECISIONS/0100-a-node-in-use-is-adopted-before-it-is-converged.md)), 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](../../01-RESEARCH/013-the-forge-and-the-registries/00-overview.md)).
|
|
|
|
**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](../088-the-forges-own-address-names-a-port-it-may-not-have/00-report.md),
|
|
[089](../089-a-contributed-route-names-a-port-the-node-may-have-moved/00-report.md),
|
|
[090](../090-the-forge-module-does-not-take-over-the-forge-genesis-raised/00-report.md).
|