jschoubben
14be8576f8
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.
2.9 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | ||
|---|---|---|---|---|---|---|
| resolved | 2026-09-22 |
|
mesh-controller bdf965d (a route names the endpoint it serves) with `portOfEndpoint` and `AtPublishedPort` — the contribution carries the endpoint's declared port and the machine-side redirection is applied to it like any other |
089 — A contributed route names a port the node may have moved
What was observed
Found in review of the fix for issue 085, 2026-09-22, by reading the controller.
A module that wants to be reachable by name contributes a route: the name, and the port on the machine that answers it. The proxy that serves the route runs on the machine's own network, so it dials that port directly.
A module's ports can be moved on one node, either because the mesh assigned a different machine port or because the node was given one as a setting (ADR 0100). Every other reader follows the move: the container's mapping, the filter, the opening, what the module says it serves, and the address consumers are told. The contribution does not. Contributions are settled without the node's port settings, deliberately — the settling step skips the ports key so that a port setting never leaks into a rendered configuration file.
So on a node where the port moved, the filter opens the port the module actually listens on, and the proxy sends the name's traffic to the port it used to listen on. The module is up, the firewall is right, and the name is dead.
Why it matters beyond this instance
Every module that contributes a route and has a movable port has this hole, and the mesh is otherwise consistent about following a moved port. It appears exactly where the migration needs it least: on a node adopted beside a predecessor, where a foundation or application port was moved precisely because the predecessor holds the usual one.
Open questions
- Should a contribution name a port at all, or only the module, with the port resolved from what that module serves on that node?
- If a contribution keeps a port, should settling apply the node's port mapping to it, while still keeping the mapping out of rendered configuration?
- What should refuse a declaration whose contributed route names a port nothing on that node listens on?
Closed
2026-09-29, in a grooming pass rather than by whoever fixed it. A route names an endpoint rather than a port, and the redirection that turns a declared port into the published one is applied to contributions too. 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.