2.5 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design |
|---|---|---|---|---|
| open | 2026-09-22 |
090 — The forge module does not take over the forge genesis raised
What was observed
Found in review of the fix for issue 085, 2026-09-22.
Genesis raises a forge before any module exists, so the mesh has somewhere to keep its own packages. The intention is that the forge's module later takes that running forge over, the way the store and the broker are taken over in place (ADR 0078).
It cannot, as things stand. The forge genesis raises and the forge the module declares differ in four ways at once:
- the container's name — the module's is not the one genesis used;
- the network — genesis runs it on the machine's own network, the module's runs bridged;
- where its data lives — genesis gives it no data volume of its own; the module mounts one;
- the address it is told to call itself — genesis sets it from the port given; the module sets none;
- the image itself. Checked in the code on 2026-09-23: the two are pinned to different digests, while the comment above the installer's constant says they are pinned identically so the module adopts the running server rather than replacing it. A comment asserting a fact about the system, and the fact is not true.
Assigning the module therefore does not adopt what is running. It raises a second forge, with a different name, on a different network, with a different data directory, beside the first.
Why it matters beyond this instance
Adoption in place is how the mesh is supposed to hand anything genesis raised to the module that owns it afterwards. It works for the store and the broker because the container's name and its data are the same on both sides. Nothing checks that a module which is meant to take over what genesis raised actually can, and the check is not hard to state: same name, same data, same network, or it is not a takeover.
Open questions
- Should genesis raise the forge exactly as the module declares it — name, network and data directory — so the module adopts it by the rule that already exists?
- Should something refuse to call a module the successor of a bootstrap service it cannot adopt?
- Is the forge's own address better resolved than set, which is issue 088?