Issue 210 resolved by mesh-host #80: an unchanged process keeps its record
This commit is contained in:
+15
-2
@@ -1,9 +1,9 @@
|
||||
---
|
||||
status: located
|
||||
status: resolved
|
||||
opened: 2026-10-03
|
||||
located-in:
|
||||
- mesh-host
|
||||
fixed-by:
|
||||
fixed-by: mesh-host #80
|
||||
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
|
||||
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.
|
||||
|
||||
## 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.
|
||||
|
||||
Reference in New Issue
Block a user