An unchanged process keeps its record, so the node's runtime is not re-created every other cycle (hq issue 210) #80

2026-10-03T11:41:27Z

mesh-admin commented

2026-10-03 11:41:27 +00:00

hq issue 210. On every machine, node-tools.runtime was logged created and restarted every ten minutes since the runtime arrived.

Cause: applyProcess's unchanged path returned an outcome with no wrote; the apply loop records every outcome, so the digest was erased from the record. The next cycle (five minutes later) found an empty record and re-created the daemon, saving the digest; the one after was unchanged and erased it again. Hence created every other cycle, which is what the laptop's journal shows at 12:09, 12:19, 12:29 … and why the state file held the digest on one read and not on the next.

Ruled out on the way: a changing secret under restart-on (the credential file untouched since the evening before; a restart owed to a sibling logs updated), unstable unit text (keys sorted), the host version (g14 runs the declared latest, 10424d2eb6a2). The live record and the live resource, run through this code in a scratch test, agreed byte for byte once the real daemon directory was used.

Fix: the unchanged path sets out.wrote = want before returning, as the file and archive appliers do. Test: one process applied three times — created, unchanged with the record intact, unchanged — and no systemctl restart after the first. The test fails on main with "an unchanged apply dropped the digest from the record". Full suite passes.

After it rolls: no created node-tools.runtime line at the next cycle, and node-tools.service's start time stops moving.

hq issue 210. On every machine, `node-tools.runtime` was logged `created` and restarted every ten minutes since the runtime arrived. Cause: `applyProcess`'s unchanged path returned an outcome with no `wrote`; the apply loop records every outcome, so the digest was erased from the record. The next cycle (five minutes later) found an empty record and re-created the daemon, saving the digest; the one after was unchanged and erased it again. Hence `created` every other cycle, which is what the laptop's journal shows at 12:09, 12:19, 12:29 … and why the state file held the digest on one read and not on the next. Ruled out on the way: a changing secret under `restart-on` (the credential file untouched since the evening before; a restart owed to a sibling logs `updated`), unstable unit text (keys sorted), the host version (g14 runs the declared latest, 10424d2eb6a2). The live record and the live resource, run through this code in a scratch test, agreed byte for byte once the real daemon directory was used. Fix: the unchanged path sets `out.wrote = want` before returning, as the file and archive appliers do. Test: one process applied three times — created, unchanged with the record intact, unchanged — and no `systemctl restart` after the first. The test fails on main with "an unchanged apply dropped the digest from the record". Full suite passes. After it rolls: no `created node-tools.runtime` line at the next cycle, and `node-tools.service`'s start time stops moving.

mesh-admin added 1 commit 2026-10-03 11:41:27 +00:00

An unchanged process keeps its record, so the node's runtime is not re-created every other cycle (hq issue 210) 482d20737f

The process applier's unchanged path returned an outcome that said nothing about what was
written; the loop recorded it like any other, erasing the digest. The next cycle found no
record and re-created the daemon, the one after found a record again, and so on: the
node's runtime restarted every ten minutes on every machine since it arrived. The outcome
now carries the digest forward, as a file's does. The test applies one process three
times and asserts the record survives an unchanged apply and no restart is asked.

mesh-admin merged commit 195fc63f6a into main

2026-10-03 11:41:34 +00:00

mesh-admin deleted branch fix/issue-210-a-process-is-unchanged-the-second-time

2026-10-03 11:41:35 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-host#80