From f554d1d4d760f5a0bfdbfb00bde776c696e20b83 Mon Sep 17 00:00:00 2001 From: teknium1 <127238744+teknium1@users.noreply.github.com> Date: Wed, 16 Sep 2026 12:39:48 -0700 Subject: [PATCH] docs(updater): say what a deferred desktop serve actually proves 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). --- hermes_cli/update_inventory.py | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/hermes_cli/update_inventory.py b/hermes_cli/update_inventory.py index 42a53be703..503c1aa235 100644 --- a/hermes_cli/update_inventory.py +++ b/hermes_cli/update_inventory.py @@ -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