hermes-admin/hermes-agent
1
0
Fork 0
Code Issues Pull Requests Actions 33 Packages Projects Releases Wiki Activity

docs(updater): say what a deferred desktop serve actually proves

Browse Source 
The match_runtime_outcomes docstring claimed a Desktop-supervised serve is
`deferred` only when the survivor probe confirmed its pre-update incarnation is
still alive. The probe itself fails closed: an unreadable process ledger lists
every planned serve as surviving, so the row is still deferred without any
liveness observation. Reword to 'when the survivor probe ran and still lists its
pid' and spell out the fail-closed caveat so the verdict does not overstate what
was verified (review follow-up on #113089).
This commit is contained in:
teknium1
2026-09-16 12:39:48 -07:00
committed by Teknium
parent 81bee00ba5
commit f554d1d4d7
1 changed files with 6 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
hermes_cli/update_inventory.py
View File

@@ -324,11 +324,12 @@ def match_runtime_outcomes(
Serve/dashboard runtimes are reconciled in their OWN vocabulary and never borrow the gateway's
outcome: with ``stale_serve_pids`` a pre-update serve whose incarnation is gone counts as
``restarted``, one still alive is ``unaccounted``; without the probe an untouched serve stays
``unaccounted``. A Desktop-supervised serve is ``deferred`` only when that probe confirmed its
pre-update incarnation is still alive: the restart phase is forbidden to restart it out from under
the app (it hosts the live Desktop chats), so it is handed back to its supervisor and surfaced.
Without that evidence it remains ``unaccounted``, rather than claiming the app owns an unknown
incarnation. See #111494.
``unaccounted``. A Desktop-supervised serve is ``deferred`` only when the survivor probe RAN
and still lists its pid: the restart phase is forbidden to restart it out from under the app (it
hosts the live Desktop chats), so it is handed back to its supervisor and surfaced. Without a
probe result it remains ``unaccounted``, rather than claiming the app owns an unknown
incarnation. The probe itself fails closed (unreadable ledger -> every planned serve is listed as
surviving), so ``deferred`` means "not shown to be gone", not "observed alive". See #111494.
See #91277.
They never borrow the gateway's outcome: ``relaunched_profiles`` and ``hermes-gateway*`` name a