Repository navigation
Seamless upgrades: hand the running core over instead of stopping it; pin core v0.82.0 - #368
Merged
Merged
Conversation
The desktop side of the core handover (control API 52). After an update is in place, the app asks its core to wait for a successor (POST /handover/arm) and restarts at once; the new version's core takes over the listeners and the old one finishes its requests. When the core cannot be armed (older core, login in progress, safe mode), the update falls back to the previous flow: wait for requests, stop, restart. - Updates: arm after replacing on macOS, Linux AppImage and Windows (installer and portable); the exit hook leaves an armed core running. The Windows installer path renames the running twcore.exe to twcore.old-<pid>.exe before the installer runs and sweeps leftovers on start; a failed install renames it back and adopts the armed core. - Linux AppImage runs core from a per-version copy in the data directory (current and previous kept), so it outlives the mount. - Restart gateway hands over to a same-version core; the supervisor lets go of the armed child, and readiness now checks that the answering core is the one it started (a takeover in progress counts as starting). - Homebrew: a quit Apple Event sent by osascript whose parent is this Homebrew's Ruby running brew.rb upgrade/reinstall arms instead of stopping core; logout/shutdown and every other sender keep today's behaviour. A replaced Info.plist (brew --no-quit etc.) triggers an armed restart. - .last-exit records whether the exit was armed; an armed exit restores the window state within five minutes even when the version is unchanged. - In-progress counts on the overview and in the menu bar include the draining core's requests; the safe-mode page says the gateway keeps the previous configuration while a takeover waits for a fixed config. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ig, translate the handover codes When the updated core cannot read the configuration it now takes over only the control plane and finishes the takeover by itself once the file is fixed. The safe-mode page says the gateway keeps forwarding on the previous configuration instead of claiming it is not running. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… a flush on a read-only handle) 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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Updates no longer cut the requests in flight. Instead of waiting for them and stopping core, the app asks the running core to wait for its successor and restarts. The new core takes over the same listening sockets, and the old one finishes its requests and exits (core 0.82.0, ThinkWatchProject/ThinkWatch-Core#370).
Changes
POST /handover/arm, restart.twcore.exeis renamed before the installer runs. Leftovers are removed at the next start.osascripton behalf ofbrew upgradeorbrew reinstallis recognised and handled like an in-app update. Any other quit stops core as before.--no-quit, SSH, automation permission denied), the app notices the new version on disk and restarts itself the same way..last-exitrecords whether the exit was armed.Status.draining).control.handover.*andgw.oauth.heldcodes; pinned to core v0.82.0. The screenshot oracle is regenerated.Testing
cargo fmt --check,cargo clippy --all-targets -D warningsandcargo test --workspacepass.tscpasses, and vitest passes (1301 tests).brew upgrade(including--no-quitand a failed upgrade), the Windows installer after the rename, and an AppImage update.🤖 Generated with Claude Code