Skip to content

Add a "check for updates" button to Settings → App - #31

Merged
MyNamesEMurray merged 1 commit into
mainfrom
claude/live-mic-transcription-accuracy-x5ptio
Sep 7, 2026
Merged

MyNamesEMurray merged 1 commit into
mainfrom
claude/live-mic-transcription-accuracy-x5ptio

Conversation

@MyNamesEMurray

Copy link
Copy Markdown
Owner

Summary

Updating was launch-only. Leave the app running in the tray for a week — which is what a tray app is for — and there was no way to ask whether a new version exists. Settings → App now has one.

Changes

The button relays to the host's updater rather than building a second update path, so finding, downloading and the restart prompt are all the flow the automatic check already uses. It reports what happened in every case — downloading, already downloaded and waiting on a restart, already current — with the version. A tray app that answers a button with silence is indistinguishable from a broken one, and a failed check must never read as "you're up to date".

Two behaviours worth calling out for review:

  • Automatic updates being off no longer disables the machinery, only the check at launch. The updater's event listeners are now wired on any packaged build. Previously they were inside the autoUpdate !== false branch, so with automatic updates off a manual check would have found an update and then done nothing with it.
  • Asking by hand clears a skip marker. "Skip this update" means stop telling me about it; clicking Check for updates is asking about that version too, so answering "you're on the latest version" would be a lie. UpdateSkip holds exactly one marker, so this is its existing clear().

Only a packaged build can update itself, so running from source passes no hook and the row stays hidden rather than being offered and then refused. The endpoint still answers there, with a sentence saying why.

Verification

  • Full CI reproduced locally: node --check over every JS file, config.example.json parse, npm test (161 pass, 0 fail, 1 pre-existing Windows-only SAPI skip), npm run smoke → SMOKE OK.
  • scripts/smoke.mjs now asserts POST /api/update/check answers 200 with ok:false and a reason when no host is attached — the headless case, where the endpoint must neither hang nor 500.
  • Exercised every state end-to-end against a stand-in host that supplies the checkUpdates hook, since Electron can't run in this environment: current{"state":"current","version":"3.8.2"}, downloading{"state":"downloading","version":"3.9.0"}, downloaded, starting, and a throwing hook → {"ok":false,"error":"net::ERR_INTERNET_DISCONNECTED"}.
  • Drove the real button in a browser against that host: the row appears only when the host advertises canCheckUpdates, the button disables while in flight and re-enables after, and the result renders as "✓ v3.9.0 found — downloading now. You'll be asked to restart when it's ready." No console errors beyond the known /favicon.ico 404.

What I could not verify here: the packaged path — a real autoUpdater.checkForUpdates() against GitHub Releases, the skip-clearing, and the restart dialog — needs a packaged Windows build. The host-side logic is small and reviewable, but it is the part that has not been run.

Risk & rollout

  • No new config keys, no migration. app.autoUpdate and app.updateChannel keep their meanings; autoUpdate: false now means "don't check at launch" rather than "don't wire the updater at all", which is the intended widening.
  • The change to when listeners are registered is the main review risk: it is what makes the button work with automatic updates off, and it means a packaged build now always has update-available/update-downloaded handlers attached. The launch-time check remains gated, so a user who turned updates off is still never prompted unless they ask.
  • Nothing touches the cast, the overlay, AI labelling, the API key handling, or Twitch access.
  • src/server.js gains one endpoint that only relays; the server still imports nothing from Electron.

Checklist

  • npm run smoke passes locally (or CI is green)
  • Follows the design language in DESIGN.md (if UI changed)
  • AI-labeling / "simulated viewers" guarantees intact (if bot output or overlay changed)
  • Docs updated (README / config reference) if behavior or config changed
  • Targets main

🤖 Generated with Claude Code

https://claude.ai/code/session_01LWa54BF5RjHWC5GFaENZMM


Generated by Claude Code

Updating was launch-only: if you left the app running in the tray for a
week -- which is what a tray app is for -- there was no way to ask.

The button relays to the host's updater rather than building a second
update path, so finding, downloading, and the restart prompt are the same
flow the automatic check already uses. It reports what happened in every
case: downloading, already downloaded and waiting on a restart, or
already current, with the version. A tray app that answers a button with
silence is indistinguishable from a broken one, and a failed check must
never read as "you're up to date".

Two behaviours worth naming:

Automatic updates being off no longer disables the machinery, only the
check at launch. The updater's listeners are wired on any packaged build,
because a manual check that found an update and then did nothing with it
would be worse than no button.

Asking by hand also clears a skip marker. "Skip this update" means stop
telling me about it; clicking Check for updates is asking about that
version too, so answering "you're on the latest" would be a lie.

Only a packaged build can update itself, so running from source passes no
hook and the row stays hidden rather than being offered and then refused.
The endpoint still answers there, which is what the smoke test asserts.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LWa54BF5RjHWC5GFaENZMM
@MyNamesEMurray
MyNamesEMurray merged commit b1fa04c into main Sep 7, 2026
2 checks passed
@MyNamesEMurray
MyNamesEMurray deleted the claude/live-mic-transcription-accuracy-x5ptio branch September 7, 2026 02:50
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.

2 participants