Skip to content

fix(update): tolerate release asset naming changes across releases - #28

Open
Nordikdata wants to merge 1 commit into
polarsource:mainfrom
Nordikdata:fix-issue-18-update-asset-fallback
Open

fix(update): tolerate release asset naming changes across releases#28
Nordikdata wants to merge 1 commit into
polarsource:mainfrom
Nordikdata:fix-issue-18-update-asset-fallback

Conversation

@Nordikdata

Copy link
Copy Markdown

What

polar update fails with No release asset found for platform: darwin-arm64 on darwin-arm64 for anyone running a binary built before the darwin .tar.gz -> .zip release asset rename (v1.3.4, 2026-04). The lookup in downloadAndUpdate matches the release asset by an exact name derived from a hardcoded os/arch->extension mapping baked into the running binary, so an older binary can never find a match again once the naming convention changes, and the same thing will happen again on any future rename.

Fix

  • Added findReleaseAsset(): tries the exact expected archive name first (unchanged fast path), then falls back to any asset for the same os/arch regardless of extension.
  • The "no asset found" error message now also suggests the one workaround that already reliably works today: reinstalling via install.sh.
  • Added tests covering the exact-match fast path, the cross-extension fallback (the actual v1.3.4 rename scenario), and that a different platform's asset is never matched.

Note: I could not reproduce the second symptom described in the issue (install.sh resolving the version string to the release title instead of the semver tag) against the current install.sh's get_latest_version() — the shipped grep/sed logic extracts tag_name correctly for the current API response shape (v1.3.9), and the live-served https://polar.sh/install.sh is byte-identical to the repo's install.sh at HEAD and at the v1.3.6 tag. Left as-is since I could not confirm a live repro; happy to dig further if it's still reproducing for you with details on your environment.

Fixes #18.

`polar update` looked up the release asset by an exact name built from a hardcoded os/arch->extension mapping. Darwin releases switched from .tar.gz to .zip in v1.3.4; anyone still running a pre-v1.3.4 binary has an update path baked in that permanently expects the old .tar.gz name, which no longer exists in newer releases, so `polar update` hard-fails with "No release asset found for platform: darwin-arm64" forever after, with no fallback and no actionable error message. The same failure mode would recur on any future naming change.

findReleaseAsset() tries the exact expected name first (no behavior change for the common case), then falls back to any archive for the same os/arch regardless of extension. The error message, if no asset is found at all, now also points at the one workaround that already reliably works today: a clean reinstall via install.sh.

Fixes polarsource#18.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

polar update fails on darwin-arm64: No release asset found

1 participant