fix(auto-update): autoDownload=true + manual-check toast gate (Greg's #314 follow-up)

[ademczuk]

Summary

Follow-up to PR #314 (closed-merged 2026-05-15). Greg signed off there with:

"I'll accept this to avoid the error conditions, but plan to move toward auto-download in the future."

This is that auto-download follow-up, marked DRAFT so it sits as an option you can pull in when ready rather than asking for review now.

What changes

Two-line behavioral change plus a small testable gate function:

1. autoUpdater.autoDownload = false -> true in AutoUpdaterService constructor. With fix(updater): drop redundant checkForUpdates that tore down Squirrel.Mac proxy (#245) #314's Squirrel.Mac proxy race fixed, the safe-choice flag flips back to its electron-updater default.
2. The update-toast:show-available send inside the update-available event handler is now gated on wasManualCheck. Background-poll updates surface only the post-download "Ready to install" toast; the manual "Check for Updates" menu item still confirms the find before bytes start arriving.
3. Gating is a one-arg pure function shouldShowAvailableToast(wasManualCheck) in autoUpdaterUtils.ts, same pattern as the classifyUpdateError extraction from fix(updater): drop redundant checkForUpdates that tore down Squirrel.Mac proxy (#245) #314. Unit-tested without booting an Electron app global.

Flow under the new policy

background poll (auto)               manual "Check for Updates"
-----------------------              --------------------------
update-available                     update-toast:checking
  (no toast - gated)                 update-available
  auto-download starts                 update-toast:show-available
  download-progress                    auto-download starts
  update-downloaded                    download-progress
  update-toast:show-ready                (renderer: 'available'->'downloading')
                                       update-downloaded
                                       update-toast:show-ready

The renderer's updateListeners.ts already transitions 'available' -> 'downloading' on the first download-progress event (line 113-118), so the manual-check toast does not get stuck on "click Download" while the bytes are already coming in.

Tests

packages/electron/src/main/services/__tests__/autoUpdater.shouldShowAvailableToast.test.ts, 3 cases:

• manual check -> returns true
• background poll -> returns false
• single boolean is the only state read (pin the contract so a future "factor in suppression" rework has to touch this test and the caller together)

Run locally, 3/3 pass. The existing autoUpdater.classifyUpdateError.test.ts (8 cases) still passes unchanged.

Why DRAFT

Two design questions I want to surface before this leaves DRAFT, both raised in my earlier reply on #314 that I never got to answer concretely:

1. Cancellation / retry hook if a newer release lands mid-download. electron-updater's internal state handles version-ahead detection on the next poll cycle automatically (4h interval), so a newer version landing during a silent download will be picked up. I did not add a separate hook because the existing poll loop covers it. Happy to add an explicit cancel-and-restart path inside AutoUpdaterService if you'd rather not rely on the poll loop alone.

2. The "Update Now" button on UpdateAvailableToast on the manual-check path. With autoDownload = true, when the user clicks "Check for Updates" and then clicks "Update Now" on the available toast, the toast button sends update-toast:download -> downloadUpdate() while electron-updater has already started the same download internally. electron-updater treats a repeat downloadUpdate() call as a no-op (returns the in-flight promise), so the user sees the toast immediately transition to 'downloading' as the existing progress events arrive. No double-download, no error. If you'd prefer the manual-check available toast to skip the "Update Now" button entirely (since the download is already happening), I can wire state === 'available' && autoDownloadInFlight to suppress the button in UpdateAvailableToast.tsx. That's a renderer-side polish so I left it out of this DRAFT.

Test plan

• npx vitest run packages/electron/src/main/services/__tests__/autoUpdater.shouldShowAvailableToast.test.ts (3/3)
• npx vitest run packages/electron/src/main/services/__tests__/autoUpdater.classifyUpdateError.test.ts (8/8 unchanged)
• npx tsc --noEmit -p packages/electron/tsconfig.json clean for the auto-update files (pre-existing lexical type errors in packages/runtime are upstream and unrelated)
• Manual smoke: trigger an alpha release, observe background poll fires only the "Ready to install" toast (no "Update Available" toast)
• Manual smoke: click Help -> Check for Updates, observe checking toast -> available toast -> downloading toast -> ready toast progression
• CI green

Refs #245 #314

[ademczuk]

Rebased onto current main (was 37 behind) and marking ready for review. CI green across all three checks.

This is the auto-download follow-up you flagged when merging #314: "I'll accept this to avoid the error conditions, but plan to move toward auto-download in the future." With #314's Squirrel.Mac proxy race fixed, autoUpdater.autoDownload flips from false back to electron-updater's own default (true). To keep the background-poll path quiet, the update-toast:show-available toast is now gated on the manual-check path via a pure helper shouldShowAvailableToast(wasManualCheck) in autoUpdaterUtils.ts (3 unit tests). Background updates surface only the post-download "Ready to install" toast; the manual "Check for Updates" menu item still confirms the find first.

One thing worth your call: auto-download now happens on metered connections too, since that is the electron-updater default we are returning to. If you would rather gate auto-download on a connection-type or settings check, I can add that, but I kept this PR to the minimal flag-flip + toast-gate you described.

[ademczuk]

Putting this back to DRAFT after a closer look. With autoDownload = true, a manual "Check for Updates" both auto-starts the download (electron-updater) and shows the available toast with a live "Update now" button. The renderer only swaps that button out for the progress UI once the first download-progress event lands (update-toast:progress). In the gap between the toast appearing and the first progress event, a click on "Update now" routes through checkAndDownloadLatest() to a second downloadUpdate(), which is the same Squirrel.Mac proxy surface #245 was about.

It is likely mitigated (electron-updater returns the in-flight download promise on a re-entrant downloadUpdate(), and the button hides quickly), but I had not actually verified that interaction before marking this ready, so DRAFT is the honest state until it is either guarded or confirmed safe. Options I am weighing: gate the manual update-toast:download path on a "download already in flight" flag, or drop the manual download trigger entirely now that autoDownload covers it. Will follow up with one of those rather than leave the race unaddressed.

[ghinkle]

It feels like Check for Update should just do the download and show the restart now toast. I think we can just get rid of the Update Available toast. I'd like to keep the manual trigger to check for download as I use that in testing frequently.

[ademczuk]

@ghinkle, I have implemented finally your direction. autoDownload is on now, so both background checks and the manual "Check for Updates" trigger download immediately, and the "Update Available" toast is gone - the flow is download in the background, then the "Ready to install" toast. The manual menu trigger stays (it kicks off the check + download you use in testing).

Rebased onto current main as a single commit, CI green. One scoping note: I removed the toast at the source (main no longer emits update-toast:show-available), so the renderer UpdateAvailableToast is now dormant rather than deleted - happy to rip the dead component out in a follow-up if you'd prefer that cleanup in this PR too.

My appologies on the delayed response, due to speaking commitments this week.