Issue 210 resolved by mesh-host #80: an unchanged process keeps its record #318

Merged
mesh-admin merged 1 commits from issues/210-resolved into main 2026-10-03 11:56:30 +00:00
Showing only changes of commit 7e464e3b22 - Show all commits
@@ -1,9 +1,9 @@
--- ---
status: located status: resolved
opened: 2026-10-03 opened: 2026-10-03
located-in: located-in:
- mesh-host - mesh-host
fixed-by: fixed-by: mesh-host #80
amended-design: amended-design:
--- ---
@@ -49,3 +49,16 @@ record, and a test that applies the same `process` declaration twice against a r
asserts the second outcome is `unchanged` with no restart — the test the shape never had. Observed asserts the second outcome is `unchanged` with no restart — the test the shape never had. Observed
on the laptop's journal and state; the other three machines' host logs are not readable by the on the laptop's journal and state; the other three machines' host logs are not readable by the
operator account over SSH, and the behaviour is the host's, not the machine's. operator account over SSH, and the behaviour is the host's, not the machine's.
## Resolution
2026-10-03, mesh-host #80. The diagnosis above was right about where and wrong about what: the
record is written every cycle, and the process applier's *unchanged* path returned an outcome that
said nothing about what was written, so the loop recorded it without the digest. The next cycle,
five minutes later, found an empty record and re-created the daemon; the one after was unchanged
and erased the digest again. `created` every other cycle is the ten-minute cadence, and it is why the
state file held the digest on one read and not on the next. The unchanged outcome now carries the
digest forward, as a file's and an archive's do. The test applies one process three times and
asserts the record survives an unchanged apply and no restart is asked; it fails on the code before.
Proven live on the laptop after the host rolled: two reconcile cycles with no `created
node-tools.runtime` line and the runtime's start time unmoved.