Issue 102 resolved and verified on the machine; issue 097's orphan was on the host network #94

2026-09-23T22:15:43Z

jschoubben commented

2026-09-23 22:15:43 +00:00

102 is closed, on the machine and not only in tests. Rolled out in two steps — the code first with the manifest unchanged, then the manifest composed by the new binary. The control plane came back holding 6852 for all three store contexts, 5679 for the bus, the broker's management port as the node gave it, and an empty value for the one address the node never moved. Its own image reference, now recorded address-free, was routed back to the node's registry port at compose. Both forwarders are stopped and removed, and with neither in place the mesh reports healthy, a push round-trips, a broker account mints through the management port, and a build runs.

Two things the review caught before they could happen, both recorded in the diagnosis: a control plane older than the manifest would have passed the unfilled request through and refused it as "not a port" — headless by exactly this issue's mechanism; and on a machine with nothing on the private network yet there is no artifact-store address at all, so a composed reference would have been refused.

097 corrected. I had called the stranded container harmless. Reading it properly: it was running on the host's own network, listening on a port on every interface, and holding open connections to the mesh's store — reaching it through one of the forwarders. What saved it was that its configuration named its own former database rather than the one the service now uses. Nothing in the mesh arranged that. Removed.

**102 is closed, on the machine and not only in tests.** Rolled out in two steps — the code first with the manifest unchanged, then the manifest composed by the new binary. The control plane came back holding 6852 for all three store contexts, 5679 for the bus, the broker's management port as the node gave it, and an empty value for the one address the node never moved. Its own image reference, now recorded address-free, was routed back to the node's registry port at compose. **Both forwarders are stopped and removed**, and with neither in place the mesh reports healthy, a push round-trips, a broker account mints through the management port, and a build runs. Two things the review caught before they could happen, both recorded in the diagnosis: a control plane older than the manifest would have passed the unfilled request through and refused it as "not a port" — headless by exactly this issue's mechanism; and on a machine with nothing on the private network yet there is no artifact-store address at all, so a composed reference would have been refused. **097 corrected.** I had called the stranded container harmless. Reading it properly: it was running on the **host's own network**, listening on a port on every interface, and holding open connections to the mesh's store — reaching it through one of the forwarders. What saved it was that its configuration named its own former database rather than the one the service now uses. Nothing in the mesh arranged that. Removed.

jschoubben added 1 commit 2026-09-23 22:15:43 +00:00

Issue 102 resolved, verified on the machine with both forwarders gone; 097's orphan was on the host network 133e10a738

The addresses follow: the control plane holds the ports the node gave, a recorded build
holds no address at all, and the two forwarders that had been holding the control plane
together are removed. 097's stranded container turned out to be listening on every
interface and connected to the mesh's store — by its own old database, which is the only
reason nothing was at risk.

jschoubben merged commit f61f047a5d into main

2026-09-23 22:15:49 +00:00

jschoubben deleted branch issues/102-resolved-and-097-worse

2026-09-23 22:15:50 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/hq#94