A route that names an endpoint still carries that endpoint's port #141

2026-09-29T09:55:44Z

mesh-admin commented

2026-09-29 09:55:44 +00:00

This would have broken every routed service on the next push. It has not, only because the mesh
still holds the previous manifests — all 25 affected modules read as behind their source right now, so
plans still render from the old shape.

Everything downstream of a route contribution reads its port. The proxy builds its target from it,
and atMachinePort — the redirection that turns a module's declared port into the number the machine
actually published — is keyed on it. A route that names only its endpoint carries no port, asPort
fails, the redirection returns the values untouched, and the proxy is handed a route with nothing to
dial.

So a contribution that names an endpoint gets that endpoint's declared port filled in, before the
name is composed. Declared and not machine: the redirection happens later and keys on the declared
number, so filling the machine port in here would be redirected a second time or not at all. A route
that repeats a port keeps it, because that is the older shape and still read.

Three tests, and the first fails with the exact symptom when the fill is removed — the route carries no port, so the proxy has nothing to dial. The second walks the whole path: declared port filled in,
then redirected to the machine's.

Also re-ran the catalogue through the real parser: 72 manifests, 75 named endpoints, 33 routed
endpoints resolved.

How I found it: I went to verify the rendered names were unchanged before pushing, read a plan that
still showed "port": 1212, and realised the plan was rendering from the old manifests — so the check
had proved nothing. Reading what fills that port in is what turned it up.

**This would have broken every routed service on the next push.** It has not, only because the mesh still holds the previous manifests — all 25 affected modules read as behind their source right now, so plans still render from the old shape. Everything downstream of a route contribution reads its `port`. The proxy builds its target from it, and `atMachinePort` — the redirection that turns a module's declared port into the number the machine actually published — is keyed on it. A route that names only its endpoint carries no port, `asPort` fails, the redirection returns the values untouched, and the proxy is handed a route with nothing to dial. So a contribution that names an endpoint gets that endpoint's **declared** port filled in, before the name is composed. Declared and not machine: the redirection happens later and keys on the declared number, so filling the machine port in here would be redirected a second time or not at all. A route that repeats a port keeps it, because that is the older shape and still read. Three tests, and the first fails with the exact symptom when the fill is removed — `the route carries no port, so the proxy has nothing to dial`. The second walks the whole path: declared port filled in, then redirected to the machine's. Also re-ran the catalogue through the real parser: 72 manifests, 75 named endpoints, 33 routed endpoints resolved. How I found it: I went to verify the rendered names were unchanged before pushing, read a plan that still showed `"port": 1212`, and realised the plan was rendering from the old manifests — so the check had proved nothing. Reading what fills that port in is what turned it up.

mesh-admin added 1 commit 2026-09-29 09:55:44 +00:00

A route that names an endpoint still carries that endpoint's port 64ba053f3b

Everything downstream reads the port: the provider is told where to reach the
consumer, and the redirection that turns a declared port into the number the
machine published is keyed on it. A route naming only its endpoint left the proxy
with no port at all, and a proxy with no port has nothing to dial.

Caught after the catalogue had already been changed to name endpoints and before
the mesh picked those manifests up, which is the only reason nothing broke: every
module's manifest is behind its source right now, so the plan still renders from
the old shape.

The declared port, not the machine one — the redirection happens later and is keyed
on the declared number, so filling in the machine port here would be redirected
twice or not at all. A route that repeats a port keeps it.

mesh-admin merged commit 9c83dacfce into main

2026-09-29 09:55:45 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-controller#141