Files
hq/04-ISSUES/088-the-forges-own-address-names-a-port-it-may-not-have/00-report.md
T
jschoubben 14be8576f8 Grooming: five issues were fixed and never closed, and one is not
088, 089, 120, 128 and 130 each name a commit that is on main and cites them —
the forge's address following a moved port, a route naming its endpoint, a
provisioner asking the backend what is there, the hosts file written into a
marked block, and undeclaring giving a unit back the state it was found in.
Each says it was closed by reading commits rather than by a run, so nobody
reads a green that was never measured.

129 stays located on purpose: ca-trust is merged and no machine holds it, so
the symptom it opened on is still true everywhere.
2026-09-29 22:25:25 +02:00

2.5 KiB

status, opened, located-in, fixed-by, amended-design
status opened located-in fixed-by amended-design
resolved 2026-09-22
mesh-catalog modules/gitea
mesh-controller internal/catalogue/declaration.go
mesh-controller 7352c84, merged in

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?

Closed

2026-09-29, in a grooming pass rather than by whoever fixed it. The forge's address follows a moved port the same way every other reader does. Found by reading what the code repositories' commits cite: the fix names this issue and is on main. It was not re-verified on a machine, and this record says so rather than implying a run that did not happen.