Repository navigation
Auto-update: don't restart onto a version that rejects the current config - #87
Merged
Merged
Conversation
…starting onto it On 2026-11-12, 0.16.0 rejected accounts.*.usage_login keys that 0.15.2 had accepted. The running server restarted onto it, and launchd then restarted it 128 times: 17 minutes with no jobs, schedules or hosted ingress. The server now runs the installed version's `config show --json` with its own home first. If that version rejects the config, the server logs an error, keeps running and checks again every minute. If the check cannot run (timeout, or node is missing), it restarts as before. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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.
Why
On 2026-11-12 at 12:20Z, the main operator daemon (0.15.2) restarted onto the newly installed 0.16.0. 0.16.0 rejects
accounts.*.usage_login, which was written for the unmerged #84. launchd restarted it 128 times (Invalid ~/.skillhook/skillhook.json: Unrecognized key "usage_login"), and for 17 min 20 s nothing ran: no jobs, no schedules, no hosted ingress. A person-equivalent fix (removing the keys) brought it back. Tracked as RA-019 in the operator's reliability backlog.What
installedAcceptsConfig(paths)insrc/update.tsrunsnode <installed dist/cli.js> config show --jsonwithSKILLHOOK_HOMEset to the server's home. It returns one of three results:ok: true: the new version loaded the config.ok: falsewith the error: the new version exited non-zero.ok: undefined: the check could not run (spawn error or a 30 s timeout).serve.tsruns the check before callingcontrol.restart():erroronce per (version, error), keeps the current version running and checks again every minute. Fixingskillhook.jsonor shipping a later release lets the restart go ahead.warnand restarts as before. A missing node binary (see serve: children spawned via process.execPath fail with ENOENT after a Homebrew node upgrade until restart #71) or a hung check under heavy load must not pin an old version forever.Tests
src/update.test.tshas unit cases for each outcome: accepted, rejected with message, bare exit code, missing executable, and timeout. They also check that the child gets this home and not the parent'sSKILLHOOK_HOME.tsx src/cli.ts) against a valid config and against one with an unknown key.pnpm testpassed 533/533,typecheckpassed,buildpassed,release --checkpassed.Reversible: the change only skips a restart. It writes no data, and the protocol is unchanged.
🤖 Generated with Claude Code