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.