Sign up
View stargazersSign up

[Bug]: desktop polls for updates every 4 minutes instead of 4 hours#28480

opened9d agobyTtao12345666333

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

  1. Run a packaged desktop build with auto-update enabled (nightly or latest channel, e.g. 0.0.42). Development builds skip the poller.
  2. Enable OTLP export under Settings → Maintenance → Diagnostics, or read the local trace log at ~/.t3/userdata/logs/desktop.trace.ndjson.
  3. Leave the app idle and count desktop.updates.checkForUpdates spans with reason: poll.

Expected behavior

The updater polls every 4 hours, about 6 checks per day. Before the Effect port, apps/desktop/src/main.ts used const AUTO_UPDATE_POLL_INTERVAL_MS = 4 * 60 * 60 * 1000;.

Actual behavior

The updater polls every 4 minutes: 360 checks per day, 60x the intended rate. Nothing deduplicates the resulting work, so each check:

  • starts a desktop.updates.checkForUpdates span (reason: poll) and a desktop.updates.handleCheckingForUpdate span, both exported over OTLP when it is configured;
  • writes checking for updates / looking for updates log lines;
  • publishes two desktopUpdateStatus telemetry messages (checking → no-update, since state updates are published unconditionally) and two UPDATE_STATE_CHANNEL IPC broadcasts;
  • sends one request to the GitHub Releases update feed (latest*.yml / nightly*.yml).

#14259 independently records the same cadence in a user trace: "The poller runs desktop.updates.checkForUpdates every 4 minutes". Anyone running OTLP export or reading trace logs sees update-check activity every 4 minutes for as long as the app is open.

Cause: #2546 (port desktop app to Effect) translated the millisecond constant to the Duration string "4 minutes" at apps/desktop/src/updates/DesktopUpdates.ts:57, dropping the hours-to-minutes factor. git show aa219be713^:apps/desktop/src/main.ts shows the previous 4 * 60 * 60 * 1000, and git log -L 56,58:apps/desktop/src/updates/DesktopUpdates.ts shows the line unchanged since that commit.

Impact

Minor bug or occasional failure — nothing breaks functionally, but every packaged install makes 60x the intended update-feed requests and emits 60x the updater spans, logs, telemetry messages, and IPC broadcasts.

Version or commit

main @ 80a2351fcb909034e65a512dfabeb3cdfd367762; regression introduced in aa219be713 (#2546).

Environment

macOS 25.6.0, packaged desktop build with OTLP export configured. The same cadence appears in the Linux AppImage trace attached to #14259.

Logs or stack traces

text
1# apps/desktop/src/updates/DesktopUpdates.ts:57
2const AUTO_UPDATE_POLL_INTERVAL = "4 minutes";
3
4# desktop.trace.ndjson, reported in #14259
518:17:08.855 -> 18:17:09.583 desktop.updates.checkForUpdates Success {reason: poll}
618:21:09.585 desktop.updates.handleCheckingForUpdate Success

Workaround

Set T3CODE_DISABLE_AUTO_UPDATE=1, or run from source, where the poller is disabled. A locally built package with "4 hours" restores the previous cadence.

Possible directions

Restore "4 hours"; I have a one-line PR ready. Optionally add jitter so instances do not poll in lockstep.

Oonlydole7d ago
Synced from GitHub

Confirmed on three Macs running the 0.1.7-nightly.20261102.4093 desktop app (macOS 27.2, Apple silicon). All three check every 240 s.

On one of them, desktop.trace.ndjson has 1,694 update checks from Oct 28 to Nov 2. The median gap is 240 s and 1,684 came from the poll timer. The rate stayed at 15 an hour between 3 and 6 am.

The issue doesn't mention a second effect. While an update is waiting, every poll finds the same version again and logs "update available". That Mac logged it 2,023 times from Oct 28 to Nov 4, against 5 downloads. Another Mac logged 159 overnight. Each poll also moves the state to checking and back, so the sidebar update button drops its Download or Install action for the length of the check. The 4-hour interval in #28481 cuts this to 6 a day. #31154 stops a poll from re-announcing the version that's already offered.

Edit: I first wrote that most of these were for a version that was already downloaded. That was wrong. Nearly all of them were for an available update that hadn't been downloaded yet.