2026-09-23 00:37:27 +00:00
2 changed files with 27 additions and 2 deletions
@@ -1,8 +1,8 @@
 ---
-status: located
+status: resolved
 opened: 2026-09-23
 located-in: [mesh-controller internal/catalogue/filtering.go, mesh-controller cmd/mesh-controller/plan.go]
-fixed-by:
+fixed-by: mesh-controller — a node may move a port a module publishes as a mapping's machine side
 amended-design:
 ---
@@ -53,3 +53,28 @@ still **stored** without a manifest in view, so a key that names nothing a modul
 accepted where it is set and refused at composition — where it stops the node being told anything
 at all, rather than stopping that module. The fix removes one reason a key could be wrong; it does
 not remove the shape of the failure. Carried to [issue 096](../096-a-setting-that-cannot-work-is-stored-and-stops-the-node/00-report.md).
 ## Resolved — 2026-09-23
 A given port names either end of a mapping and is answered **once**, under the end the module
 names in its own `listens` — the number the plan, the filter, the openings, the guard and the
 consumer all ask for. A number that names two of a module's mappings is refused, whether the
 setting used it or the answer would be filed under it.
 The first pass filed the answer under both ends. Review found that this is wrong wherever two
 mappings share a number: the second key lands where another mapping's reader looks, the later
 write wins, and a module publishing `8080:80` beside `9090:8080` had an explicit setting silently
 replaced — the container moving to one number while the filter, the opening and the consumer kept
 another. Reintroducing the fault, inside the fix for it. Two mappings onto one machine port came
 with it, where before the setting had been safely refused. Neither was reachable against the
 catalogue as it stands; both were silent, which is worse than reachable.
 **Verified on the machine**, not only in tests: the forge was given `{"2222": 222}`, its container
 now publishes `222:22`, the opening derived for it is `tcp-222-forwarded` to 22 from anywhere —
 the node's `expose` for that port carried across the move — and nothing is opened at the number it
 left. Git over ssh answers from outside again, on the port the forge's own configuration has
 advertised in every clone URL all along.
 Checked from the other side as well, and it matters: `SSH_PORT` in the forge's configuration says
 222. While the port could not be moved, the mesh published 2222 and the forge told everyone 222.
 A service can be wrong about itself without anything failing.