2.0 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design |
|---|---|---|---|---|
| open | 2026-09-22 |
088 — The forge's own address names a port it may not have
What was observed
Found while fixing issue 085, 2026-09-22, by reading the catalogue rather than by running it.
The forge's module declares its own address as an environment value on its container, written out in full with the port in it. Its container publishes its port without fixing the machine side, so the mesh assigns that side — which is already, today, usually not the number written into the address. The address is therefore wrong on any node where the assignment differs, and it becomes wrong for a second reason once a node is given that port as a setting (ADR 0100).
The mesh has the right answer for this: a placeholder that resolves to the port actually in use. It is substituted in file resources only, and this value is in a container's environment map, where nothing substitutes it.
Why it matters beyond this instance
Two rules of the mesh meet here and neither is enforced. A module may not name a port it does not control, and what a module is told about an address must come from what the provider serves. Any module that writes its own address into an environment value has the same hole, and nothing checks for it: the value is a string like any other, and it is wrong only at runtime, on the node where the assignment happens to differ.
Open questions
- Should the port placeholder resolve in a container's environment as it does in files, or should a module that needs its own address be made to carry it in a file?
- Should composition refuse an environment value that names a port the module does not fix, the way it refuses other claims a module cannot make?
- Which other modules write their own address, with a port, into their environment?