Issue 094 diagnosed and resolved; 096, 097 and 098 opened from what it uncovered #84

2026-09-23T00:37:23Z

jschoubben commented

2026-09-23 00:37:23 +00:00

094 — diagnosed and resolved. One blind spot read from two ends: the check that refused the
setting collected only the last segment of each published entry, and the lookup that would have
made the other half useful reads the same map under two different keys. Fixed in mesh-controller
(#47) and verified on the machine — the forge publishes 222:22, the opening follows, and git over
ssh answers from outside on the port the forge's own SSH_PORT has advertised all along.

The first pass answered under both ends of a mapping. Review showed that is the same fault seen
from the other side wherever two mappings share a number, so the answer is now filed once, under
the end the module itself names. Written up in the diagnosis, because it is a mistake worth being
able to find again.

Three issues opened from what the work turned up:

096 — a setting that cannot work is accepted where it is set, and stops the node where it is
read. 094's push-blocking half, which its fix does not close: settings are stored without a
manifest in view, and composition fails the node rather than the module, so one typo silences a
machine at a distance from its cause.
097 — a resource whose target changes leaves the old one behind, running. Found looking at
what the forge's cutover left on the machine: the host keeps one record per resource holding its
current target, so renaming a container erased the only trace of the one to remove. It is still
running, undeclared, unreported, and would survive a reboot.
098 — taking a module replaces a configuration nobody compared. Found reading the next
cutover instead of running it: the catalogue's config file drops a rule the machine's has, no
step puts the two side by side, and there is no mechanism to carry the difference — content takes
no settings, and writing into a file is JSON-only.

**094 — diagnosed and resolved.** One blind spot read from two ends: the check that refused the setting collected only the last segment of each published entry, and the lookup that would have made the other half useful reads the same map under two different keys. Fixed in mesh-controller (#47) and verified on the machine — the forge publishes `222:22`, the opening follows, and git over ssh answers from outside on the port the forge's own `SSH_PORT` has advertised all along. The first pass answered under *both* ends of a mapping. Review showed that is the same fault seen from the other side wherever two mappings share a number, so the answer is now filed once, under the end the module itself names. Written up in the diagnosis, because it is a mistake worth being able to find again. Three issues opened from what the work turned up: - **096 — a setting that cannot work is accepted where it is set, and stops the node where it is read.** 094's push-blocking half, which its fix does not close: settings are stored without a manifest in view, and composition fails the node rather than the module, so one typo silences a machine at a distance from its cause. - **097 — a resource whose target changes leaves the old one behind, running.** Found looking at what the forge's cutover left on the machine: the host keeps one record per resource holding its *current* target, so renaming a container erased the only trace of the one to remove. It is still running, undeclared, unreported, and would survive a reboot. - **098 — taking a module replaces a configuration nobody compared.** Found reading the *next* cutover instead of running it: the catalogue's config file drops a rule the machine's has, no step puts the two side by side, and there is no mechanism to carry the difference — content takes no settings, and writing *into* a file is JSON-only.

jschoubben added 3 commits 2026-09-23 00:37:23 +00:00

Issues 096 and 097, and 094 diagnosed: a setting stored where it cannot work, and a resource that changed target 235b9ea0e5

094's cause is one blind spot read from two ends, written up in its diagnosis; the fix
answers the first open question and not the other two, which become 096. 097 was found
looking at what the forge's cutover left running.

Issue 098: taking a module replaces a configuration nobody compared 0c8615aa8f

Found reading the second module's cutover rather than running it: the catalogue's
config drops a rule the machine's has, and no step puts the two side by side.

Issue 094 resolved: a given port names either end and is answered once 668ce3ad62

The first pass answered under both ends, which review showed is the same fault seen
from the other side where two mappings share a number. Verified on the machine: the
forge is back on the port its own configuration has always advertised.

jschoubben merged commit cda7a4e348 into main

2026-09-23 00:37:27 +00:00

jschoubben deleted branch issues/094-diagnosis-and-096

2026-09-23 00:37:27 +00:00

jschoubben referenced this pull request

2026-09-25 22:54:37 +00:00

Research 017: a mesh that heals itself #115

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/hq#84