50 lines
2.3 KiB
Markdown
50 lines
2.3 KiB
Markdown
---
|
|
status: open
|
|
opened: 2026-09-22
|
|
located-in: []
|
|
fixed-by:
|
|
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?
|