fix(gateway): wait for launchd restart readiness in-band (#56524) - #735
Open
hashbender wants to merge 1 commit into
Open
fix(gateway): wait for launchd restart readiness in-band (#56524)#735hashbender wants to merge 1 commit into
hashbender wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Fixes the macOS launchd in-band restart/update path so Hermes does not report success before a fresh gateway process is actually runtime-ready.
The old self-restart path returned immediately after sending
SIGUSR1, which lethermes update/hermes gateway restartcomplete while the old gateway was still draining and before launchd had confirmed a healthy replacement. In the gateway-hosted terminal path, that also left fallbacklaunchctl kickstart -kvulnerable to being killed with the old gateway process group.This PR waits for the old PID to exit, waits for a fresh launchd-managed PID to reach
gateway_state=running, and uses a detached watcher plus a shared launchd recovery helper so forced fallback survives in-band teardown.Related Issue
Fixes NousResearch#56524
Type of Change
Changes Made
hermes_cli/gateway.py_wait_for_pid_exit()and_wait_for_launchd_service_restart()so launchd restart success means a fresh runtime-ready gateway PID, not just a signal requestkickstart/ unloaded-job recovery / detached fallback behind_kickstart_launchd_service_and_wait()launchd_restart()through the shared recovery path and only clear the unsupported marker after runtime-ready recoverytests/hermes_cli/test_gateway_service.pylaunchctl kickstart -kNonePID gapbootout -> bootstrap -> kickstartHow to Test
#56524:✓ Service restart requestedimmediately afterSIGUSR1, before launchd runtime-ready confirmation./scripts/run_tests.sh tests/hermes_cli/test_gateway_service.py -k 'launchd_restart_drains_running_gateway_before_kickstart or launchd_restart_self_request or wait_for_launchd_service_restart_timeout_reports_logs or launchd_restart_boots_out_stale_registration_before_bootstrap or launchd_restart_falls_back_to_detached_on_error_5'.venv/bin/python -m pytest -q tests/hermes_cli/test_gateway_service.py -k 'launchd_restart_self_request or wait_for_launchd_service_restart_timeout_reports_logs'ruff check hermes_cli/gateway.py tests/hermes_cli/test_gateway_service.pygit diff --check.venv/bin/python -m pytest -q tests/hermes_cli/test_gateway_service.py182 passed, 6 failed; the 6 failures are the pre-existing user-systemd baseline failures, unrelated to this patchChecklist
Code
fix(scope):,feat(scope):, etc.)pytest tests/ -qand all tests passDocumentation & Housekeeping
docs/, docstrings) — or N/Acli-config.yaml.exampleif I added/changed config keys — or N/ACONTRIBUTING.mdorAGENTS.mdif I changed architecture or workflows — or N/AScreenshots / Logs
N/A
Mirror-of: NousResearch#56908
NousResearch#56908