Update check intermittently fails: GitHub 406 on releases Atom feed (packaged app still points at Maka-Agent/maka-agent)

[baoyu0]

Summary

Maka Desktop (packaged, v0.1.11) intermittently shows an error toast on startup update check: "检查更新失败 / Cannot parse releases feed". The underlying electron-updater failure is a transient HTTP 406 Not Acceptable from GitHub while resolving the "latest" release through the GitHub releases Atom feed, combined with a stale publish config (Maka-Agent/maka-agent) in the packaged app after the repository moved to apache/maka.

Impact today: none functionally — installed v0.1.11 is the newest production release (newer feed entries are 0.2.0-dev.* nightly snapshots, explicitly non-Apache releases). The error is a false alarm, but it is user-visible and confusing.

Environment

• Maka: 0.1.11, Build: packaged
• Electron 43.2.0 / Chrome 150.0.7871.129 / Node 24.18.0
• OS: win32 10.0.26200 (x64), Locale zh-CN
• Error captured: 2026-09-04T14:55:37Z (GitHub edge region: japaneast)

Observed error

Cannot parse releases feed: Error: Unable to find latest version on GitHub
(https://github.com/Maka-Agent/maka-agent/releases/latest), please ensure a production release exists:
HttpError: 406  "method: GET url: https://github.com/apache/maka/releases ..."

Stack (electron-updater):

GitHubProvider.getLatestTagName
  -> GitHubProvider.getLatestVersion
  -> AppUpdater.getUpdateInfoAndProvider
  -> NsisUpdater.doCheckForUpdates

Root cause analysis

1. Stale publish config. The packaged resources/app-update.yml still contains:

   owner: Maka-Agent
   repo: maka-agent
   provider: github

   github.com/Maka-Agent/maka-agent permanently 301-redirects to https://github.com/apache/maka (verified: Location: https://github.com/apache/maka). The updater therefore relies on a redirect hop to reach the real repository.

2. Intermittent 406 on Atom content negotiation. electron-updater requests the releases list with Accept: application/atom+xml. GitHub currently answers GET /releases/latest with 302 → /releases, and serves the Atom feed on /releases for that Accept header — but intermittently answers with HTTP 406 Not Acceptable + empty body (headers in the failing response: content-type: text/html, content-length: 0, GitHub CSP error page style). Reproduction on the same day, minutes after the failure:

   curl -s -D - -H "Accept: application/atom+xml" https://github.com/apache/maka/releases
   # -> 200, application/atom+xml; charset=utf-8  (full feed, identical to the XML embedded in the failed run)

   The identical request that 406'd succeeded immediately on retry, so this is a transient server-side content-negotiation refusal, not a permanently broken endpoint.

3. Failure propagation. On 406 there is no feed to parse, so electron-updater throws Unable to find latest version on GitHub (…), please ensure a production release exists and the app surfaces it as Cannot parse releases feed.

4. Nightly noise. The feed's newest entries are 0.2.0-dev.* "Desktop Nightly" snapshots (built by github-actions, DISCLAIMER-WIP, "not an Apache Release"). The newest production release is v0.1.11 (2026-08-18), which is the installed version. Any latest-release resolution that is not robust against pre-releases/nightlies will keep misbehaving as the project publishes nightlies more frequently than stable releases (cf. fix: pin Desktop Nightly feed channel #4266 "pin Desktop Nightly feed channel").

Suggested fixes

• Update the electron-builder publish config (and thus the generated app-update.yml) to the canonical owner: apache / repo: maka so packaged apps stop depending on the Maka-Agent → apache 301 redirect.
• Do not resolve "latest" via HTML/Atom content negotiation on the web URL. Prefer the GitHub API releases/latest endpoint (a GH_TOKEN/token avoids rate limits) or the canonical releases.atom URL with an explicit User-Agent; either way, retry once on 4xx/parse failures before surfacing an error.
• Keep stable releases as proper electron-updater targets (non-prerelease tag, assets including latest.yml) and keep nightly dev snapshots off the same "latest" semantics.
• Treat transient update-check failures as non-fatal (no error-level toast / no latching), consistent with The update panel latches one error and labels a provenance failure as a check failure #4708 on update-panel error handling.

Notes

Full diagnostics (captured response headers, the exact feed XML) are available on request.

[Adarsh-Me]

take