028 fixed — the mesh assigns the port, and knows what it cannot move

A module now says its port once, in `listens`, and the container's
mapping, the rule set and what a consumer is told are all derived from
one assignment. The three hand-written copies that agreed only because
one person wrote them are gone.

The half that made this an issue rather than an inconvenience was that
the substrate is not a module: nothing in the mesh had heard of its own
store, so it handed a database module the port the store already had.
The machine now says what it carries, and the mesh assigns around it.

Ports the protocol fixes became claims, which needed no new mechanism —
the mesh already had one for what is singular on a machine.

Left open, and unchanged by any of this: whether a module should publish
to the machine at all. Assignment makes publishing safe without making
it necessary.
This commit is contained in:
2026-09-01 18:32:58 +02:00
parent c2a37ab7f8
commit 0bcfeb4e80
@@ -1,8 +1,8 @@
---
status: located
status: fixed
opened: 2026-09-01
located-in: [mesh-control]
fixed-by:
located-in: [mesh-control, mesh-host]
fixed-by: mesh-control 1f5b70a, 41f7c51; mesh-host b91342a
amended-design: 02-DECISIONS/0038-the-mesh-assigns-the-port.md
---
@@ -71,3 +71,29 @@ The record also names what this issue missed: the same number is written **three
module — once for the rule set, once for what a consumer is told, once for what the runtime
publishes — and nothing checks that they agree. A module whose `serves` and whose container
disagreed would hand every consumer a port that answers nothing.
## Fixed
**The mesh assigns the machine-side port**, from a high unprivileged range, recorded per machine
and module and kept once chosen. A module says the port its software uses, once, in `listens`. The
container's mapping, the rule set, and what a consumer is told are all derived from the assignment
— so the three copies that agreed only because one person wrote them are now one fact.
**A port the protocol fixes says so**, and is then a claim: one holder per machine, and the second
refused by name at assignment rather than by a container runtime at apply.
**And the machine says what it already holds.** This was the half that made the issue: the
substrate is not a module, so nothing in the mesh had heard of the store or the broker. The host
already distinguished what it carried from what the mesh sent — that distinction exists so the two
never remove each other — and now records what each resource binds and reports the carried ones.
The allocator treats those as taken.
What the declaration binds, not what is open: a machine's open ports are a moving target, and
assigning around those would mean a port that was free when it was asked for and taken when it was
used.
## What it does not settle
The question underneath, unchanged: **whether a module should publish to the machine at all**.
Assignment makes publishing safe without making it necessary, and consumers reaching a provider on
the module's own network by name would make the question moot for anything inside the mesh.