Files
orca/src/main
Neil 22a9e30ba1 test(updater): detach stale updater module instances from the shared autoUpdater mock (#17649)
Root cause of the `updater.startup-scheduling` flake: `resetUpdaterMocks()` calls
`vi.resetModules()`, which abandons the previous test's `updater` module instance but
cannot cancel the real timers that instance already armed. The earlier real-timer tests
leave a 1s `updateCheckSilentSettleTimer` pending; it fires a second or so later, i.e.
during a *later* test that has since installed a fake clock. The abandoned instance then
runs `completeSilentUpdateCheck()` -> `scheduleAutomaticUpdateCheck(24h)`, arming that
timer on the running test's fake clock at its epoch. `reschedules the next automatic
check 24 hours after finding an available update` advances 1h + 23h, so the stale 24h
timer lands exactly at the end of the 23h window, and the stale instance calls the
shared `autoUpdaterMock.checkForUpdates` spy -> 2 calls instead of 1.

Whether the leaked real timer fires before or after the next test installs its fake
timers is real-clock dependent, which is why it reproduced ~1 in 12 runs and only when
the whole file runs (30/30 pass with `-t` filtering to the single test).

This is a test-isolation bug, not a product bug: production has exactly one updater
module instance and one clock, so no stale instance can exist.

Fix: the harness already detaches abandoned instances on the event side (it clears the
`app`/`autoUpdater` handler maps on reset); extend the same idea to the call side.
`loadElectronAutoUpdater()` now hands each module instance a generation-stamped view of
`autoUpdaterMock`, and `reset()` bumps the generation, so a stale instance's calls and
property writes are dropped instead of driving the spies the running test asserts on.

Verified: 40/40 clean runs of `pnpm test src/main/updater.startup-scheduling.test.ts`
(0 failures), plus all 22 `src/main/updater*` files (264 tests) green.
2026-08-31 00:55:01 -07:00
..
…