The provider remap moves a port; it does not bind it to loopback #20

2026-09-11T20:34:27Z

jschoubben commented

2026-09-11 20:34:27 +00:00

postgres and lavinmq carried 127.0.0.1: in their host-port remap, and it broke a consumer on a node that has no substrate to collide with.

A module is told to reach its provider at <node>.internal; that name is the node's overlay address; a provider listening only on loopback refuses it. letta on ace died of exactly this — "is the server running on that host and accepting TCP/IP connections?" — while postgres sat healthy beside it on the same machine.

The collision needed a different port, which is what every other entry in that table does ("8090:80"). The address was never part of it, and adding it made the provider unreachable by the one name the mesh hands its consumers.

Worth recording why this took a while to see: hq issue 038 was filed on this exact symptom, narrowed to a port mismatch in mesh-control — which was real and is fixed — and the loopback half was written off as a stale build. Both halves were true; only one of them was the mesh's. publishedOn emits "15432:5432" with no address and mesh-host adds none, so the mesh was clean and the bed was not.

Typecheck clean, 149 unit tests.

`postgres` and `lavinmq` carried `127.0.0.1:` in their host-port remap, and it broke a consumer on a node that has no substrate to collide with. A module is told to reach its provider at `<node>.internal`; that name is the node's overlay address; a provider listening only on loopback refuses it. **letta on ace** died of exactly this — *"is the server running on that host and accepting TCP/IP connections?"* — while postgres sat healthy beside it on the same machine. The collision needed a different **port**, which is what every other entry in that table does (`"8090:80"`). The address was never part of it, and adding it made the provider unreachable by the one name the mesh hands its consumers. Worth recording why this took a while to see: hq issue **038** was filed on this exact symptom, narrowed to a *port* mismatch in mesh-control — which was real and is fixed — and the loopback half was written off as a stale build. Both halves were true; only one of them was the mesh's. `publishedOn` emits `"15432:5432"` with no address and mesh-host adds none, so the mesh was clean and the bed was not. Typecheck clean, 149 unit tests.

jschoubben added 1 commit 2026-09-11 20:34:28 +00:00

The provider remap moves a port; it does not bind it to loopback 3f58a0a08f

postgres and lavinmq carried 127.0.0.1: in their remap, and it broke a consumer
on a node that has no substrate to collide with. A module is told to reach its
provider at <node>.internal, that name is the node's overlay address, and a
provider listening only on loopback refuses it — letta on ace failed with 'is the
server running on that host and accepting TCP/IP connections?' while postgres sat
healthy beside it.

The collision needed a different port, which is what every other entry here does.
The address was never part of it, and it made the provider unreachable by the one
name the mesh hands its consumers.

Claude-Session: https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF

jschoubben merged commit 06d22320f8 into main

2026-09-11 20:34:42 +00:00

jschoubben deleted branch fix/the-remap-moves-a-port

2026-09-11 20:34:42 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-lab#20