Issue 085: the packages port given at genesis is not a setting, and a later module can undo it

2026-09-22 18:17:21 +02:00
parent 213ab898d6
commit 019184ec0f
1 changed files with 49 additions and 0 deletions
@@ -0,0 +1,49 @@
+---
+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?