Issue 109: a container keeps the address it was made with #96

2026-09-23T23:02:42Z

jschoubben commented

2026-09-23 23:02:42 +00:00

Found live, minutes after the mesh took over the predecessor's tunnel. Adopting it moves the mesh onto the tunnel's range, so the hub's private address changed. Everything the controller composes followed within one push; nothing on the machine did. The forge's container carried the old address in its own hosts file, written when it was created, lost its database, reported healthy while its existing connections lasted, and then the public name went down. Removing it and letting the mesh make it again fixed it in one step.

The service beside it was untouched by the same change — it sits on a network of its own and asks a resolver for the name instead of reading a copy of the answer. Only a container on the runtime's default network gets it baked in.

This is issue 102's rule — an address is read where it is used, never recorded — broken one level further down: the controller obeys it, then the runtime writes the answer into the container for the life of that container. And it is issue 103's fix stopping one input short: that made the content of a file a container reads part of what the host compares; the hosts entries it is made with are the same kind of input and are not compared.

Open: compare them and accept that a node's address change restarts every container on it, or give a container no answer at all and make the resolver a dependency of every module — which is what the containers that survived this already do.

Found live, minutes after the mesh took over the predecessor's tunnel. Adopting it moves the mesh onto the tunnel's range, so the hub's private address changed. Everything the controller composes followed within one push; nothing on the machine did. The forge's container carried the **old** address in its own hosts file, written when it was created, lost its database, reported healthy while its existing connections lasted, and then the public name went down. Removing it and letting the mesh make it again fixed it in one step. The service beside it was untouched by the same change — it sits on a network of its own and asks a resolver for the name instead of reading a copy of the answer. Only a container on the runtime's default network gets it baked in. This is issue 102's rule — an address is read where it is used, never recorded — broken one level further down: the controller obeys it, then the runtime writes the answer into the container for the life of that container. And it is issue 103's fix stopping one input short: that made the *content of a file* a container reads part of what the host compares; the hosts entries it is made with are the same kind of input and are not compared. Open: compare them and accept that a node's address change restarts every container on it, or give a container no answer at all and make the resolver a dependency of every module — which is what the containers that survived this already do.

jschoubben added 1 commit 2026-09-23 23:02:42 +00:00

Issue 109: a container keeps the address it was made with 6ccd138729

Found when adopting the tunnel moved the hub's address: the declaration followed, the
running container did not, and the forge lost its database. Issue 102's rule broken one
level down, and issue 103's fix stopping one input short.

jschoubben merged commit 0e70ca0808 into main

2026-09-23 23:02:49 +00:00

jschoubben deleted branch issues/109-a-container-keeps-the-address-it-was-made-with

2026-09-23 23:02:49 +00:00

jschoubben referenced this pull request

2026-09-26 14:47:19 +00:00

Issue 124: a consumer cannot be told a value its provider derived for it #127

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/hq#96