fix(updater): name macOS updater archives per-arch so the manifest can serve them#119
Merged
Merged
Conversation
…n serve them
The macOS auto-updater silently no-op'd on every machine: click Update →
"downloads" → restarts → same version, still pending.
Root cause: Tauri bundles the macOS updater archive as an arch-less
`OpenBook.app.tar.gz`, but the account server's manifest selects the macOS
asset only by an arch-suffixed name (`OpenBook_<ver>_{aarch64,x64}.app.tar.gz`).
The arch-less name matched nothing, so the manifest returned 204 ("up to date")
to every macOS caller — even with a newer release out. Worse, both macOS matrix
legs uploaded the same `OpenBook.app.tar.gz` with `--clobber`, so only one arch
ever survived.
Fixes:
- release.yml renames the macOS updater archive (and its detached `.sig`)
per-arch before upload, matching the name the manifest expects and stopping
the two legs from clobbering each other. Signature-safe: the `.sig` signs the
archive bytes, not the filename.
- `downloadAndInstall()` now returns whether an update was actually staged
(false on the 204 no-op). The Settings action and background scheduler gate
the relaunch / "ready to restart" toast on that, so a no-op never triggers a
pointless restart onto the same version — Settings shows a clear note instead.
Cutting this release republishes the macOS updater assets under the correct
names, which also unbreaks existing 1.76.0 users (the manifest is dynamic and
reads the latest release's assets).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KFk2T9k3p7ghCjdzMfkA5w
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
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.
The bug
The macOS auto-updater silently no-op'd on every machine: click Update → "downloads" → app restarts → same version, still pending.
Root cause
Tauri bundles the macOS updater archive as an arch-less
OpenBook.app.tar.gz, but the account-server manifest (open.book.publib/updates.ts) selects the macOS asset only by an arch-suffixed name —OpenBook_<ver>_{aarch64,x64}.app.tar.gz. The arch-less name matched nothing, so the manifest returned 204 "up to date" to every macOS caller even with a newer release out. Verified live againstaccount.book.pub: the manifest 204s for everycurrent_versiondespite v1.76.0 being latest.Secondary: both macOS matrix legs uploaded the same
OpenBook.app.tar.gzwithgh release upload --clobber, so only one arch's archive ever survived on a release.Symptom chain: manifest 204 → Tauri
check()returns null →downloadAndInstall()no-ops → but the Settings action / background scheduler relaunched (or toasted "ready to restart") anyway → app restarts unchanged, while the separate informational/checkendpoint still shows "update pending".Fixes
.github/workflows/release.yml— rename the macOS updater archive (and its detached.sig) per-arch before upload, matching the name the manifest expects and stopping the two legs from clobbering each other. Signature-safe: the.sigsigns the archive bytes, not the filename.downloadAndInstall()now returns whether an update was actually staged (falseon the 204 no-op). The Settings action (UpdatesSection) and the background scheduler (UpdateScheduler) gate the relaunch / "ready to restart" toast on that, so a no-op never triggers a pointless restart onto the same version — Settings shows a clear inline note instead.Why cutting this release fixes live users
The manifest endpoint is dynamic and reads the latest release's assets. Once v1.76.1 ships with correctly-named
OpenBook_1.76.1_{aarch64,x64}.app.tar.gz+.sig, an existing 1.76.0 machine hitting the manifest gets a valid 200 and can finally update (its compiled-in pubkey still matches — same signing key). So this repairs current macOS installs, not just future ones.Verification
nx release --dry-run→ derives a patch bump to v1.76.1 from this commit.updateRunner+UpdateSchedulertests).ui,app,web.🤖 Generated with Claude Code