fix(updater): restart on Linux/macOS after install - #73
Merged
Conversation
`tauri-plugin-updater::download_and_install` only calls `std::process::exit(0)` on Windows (where the NSIS/MSI installer takes over the running process). On Linux and macOS it writes the new binary to disk and returns — the caller has to restart. Without an explicit `app.restart()`, the in-app updater on Linux and macOS hits 100% download, the `Finished` event fires, and then nothing else happens — the running process keeps the old binary loaded and the UI is stuck in `installing: true` forever. Affects both stable and pre-release channels (the install path is shared). Surfaced now because the new pre-release opt-in toggle made testers actually exercise the in-app updater on Linux for the first time. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Nic-dorman
added a commit
that referenced
this pull request
May 1, 2026
Third internal-tester pre-release. Adds on top of rc.2: - Linux/macOS auto-restart after install (#73) -- closes the "stuck at 100%" bug where the install completed but the running process kept the old binary. - Teal banner + dialog badge for prerelease updates (#74) -- visual consistency with the sidebar PRE-RELEASE indicator. Closes the V2-237 install path on Linux. Tested on Ubuntu 25.10 with the rc.1 -> rc.2 upgrade in #73. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Nic-dorman
added a commit
that referenced
this pull request
May 1, 2026
Fourth internal-tester pre-release. Adds on top of rc.3: - "Pre-Release" header line above the teal "Update Available" banner (#76) -- testers see the channel of the offered update at a glance without having to parse the version string. Cut quickly after rc.3 so testers on rc.1/rc.2 (Linux/macOS) can exercise the V2-237 + #73 install path twice: once upgrading to rc.3, then again from rc.3 to rc.4 (verifies the fix is sticky across multiple upgrade cycles). Co-authored-by: Claude Opus 4.7 (1M context) <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
1 participant
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.
Summary
tauri-plugin-updater::download_and_installonly callsstd::process::exit(0)on Windows (seetauri-plugin-updater-2.10.1/src/updater.rs:288, where the comment explicitly says "exit the app throughstd::process::exit(0)on Windows"). On Linux and macOS it just writes the new binary to disk and returns — the caller has to restart the app explicitly.Without that restart, on Linux/macOS:
Finishedevent firesinstall_pending_updatereturnsOk(())installing: trueforeverWindows is unaffected because the NSIS installer's
process::exitpath insidedownload_and_installalready tears the running process down, and the installer relaunches the new binary itself.The fix is one line: call
app.restart()afterdownload_and_installreturns.AppHandle::restart()returns!, so it replaces the trailingOk(()). On Windows it's harmless — the installer is already exiting the process by the time control would reach it.Scope
Affects both stable and pre-release channels — the install path is shared. Technically the same bug existed pre-rc.1 (the JS plugin's
Update.downloadAndInstall()also doesn't auto-restart on Linux/macOS — same comment instores/updater.tsclaimed it did) but stable users on Linux/Mac generally don't update via the in-app flow, so it went unnoticed. The new pre-release opt-in toggle (#68) is what made testers actually hit it.Test plan
Verified locally on Ubuntu 25.10 (kernel 6.17, x86_64):
0.6.8-rc.1AppImage with the fix, opted in to pre-release, triggered update against published rc.2 → download completes, app exits, relaunches as rc.2stores/updater.ts:86is now accurate (Rust side actually does restart)restart()would run)🤖 Generated with Claude Code