Ente Auth Slow/Laggy Startup MacOS

[bradwba]

[Auth] Desktop client freezes on launch and after periods of inactivity (main-thread stall)

App: Ente Auth, desktop (io.ente.auth.mac)
Platform: macOS
Versions affected: 4.3.2+432 and 4.4.23+1023 (both, see below)

Summary

The desktop client becomes unresponsive for several seconds (observed up to ~22s, occasionally never completing) at two points:

• On a cold launch, after the home screen renders but before any code is usable.
• When the app has been left open and is returned to after a period of inactivity.

During the freeze the UI, menus, and code list are all unresponsive. Once the blocking sync resolves, the app is fast and subsequent syncs complete in under 300ms. This is not network latency and not data volume; the UI isolate is blocked.

Reproduction

Intermittent, with no reliable external trigger identified:

• Cold launch: Freezes for several seconds to tens of seconds before the code list becomes usable.
• Idle return: leave the app open and unattended for a while, then return to it. Interacting (opening menus, reading a code) is laggy or frozen for several seconds.

Evidence: this is a main-thread stall, not a network wait

The independent UpdateService debounce timer goes silent for the entire freeze and only fires at the moment the sync finally resolves, i.e. the whole UI isolate is blocked and everything queued flushes at once. A network wait on the sync request could not also stall the unrelated update-check timer.

Slow launch (~9.8s), 4.4.23+1023:

[main][INFO] [2026-06-10 15:34:32.570098] Starting app in foreground
[Configuration][INFO] [2026-06-10 15:34:32.588914] Cleared temp folder
[AuthenticatorService][INFO] [2026-06-10 15:34:32.591482] Initiating remote to local sync
[HomePage][INFO] [2026-06-10 15:34:35.056118] No initial link received.
[UpdateService][INFO] [2026-06-10 15:34:42.170880] Debouncing notification
[AuthenticatorService][INFO] [2026-06-10 15:34:42.365794] 0 entries fetched from remote
[AuthenticatorService][INFO] [2026-06-10 15:34:42.365856] remote fetch completed

Here nothing logs between HomePage at 35.056 and the UpdateService debounce at 42.170. The event loop is blocked for those ~7 seconds, then the debounce and the sync completion both fire together. The same blocking sync runs on the periodic/idle-return path, which is consistent with the freeze also appearing after inactivity.

Network ruled out

curl against the same API host, warm, is consistently fast and stable, so transport is not the cause:

dns:0.003  connect:0.012  tls:0.028  ttfb:0.220  total:0.220

DNS, TCP connect, and TLS all finish inside ~30ms and server TTFB is ~220ms across repeated calls. The multi-second freezes are an order of magnitude larger than the entire wire round trip.

Notes that may help narrow it

• Not version specific: reproduced on both 4.3.2+432 and 4.4.23+1023, so the recent builds neither introduced nor fixed it.
• Not data volume: the freezing sync returns 0 entries fetched from remote.
• Not local cache: fully clearing the app container (logout + rebuild, re-pulling all 95 entries) did not stop it; freezes returned on the next launches.
• Temp folder state is not the cause: a Cleared temp folder launch (15:34:32 above) froze for ~9.8s, while later Skipping temp folder clear launches were both slow and (once) instant. No correlation.

Expected behavior

Locally stored codes should render and remain usable immediately, with sync running in the background without ever blocking the UI, whether on launch or after the app has been idle.

Possibly related

#3898 ([Auth] Desktop Client Randomly Freezes) describes the same foreground-idle freeze and shows the same log signature (long gap between sync initiation and entries fetched from remote), but without an identified cause. This report adds the main-thread-stall evidence and confirmation across versions.

[CoderDeltaLAN]

Your diagnosis looks right the log gap between HomePage and the debounce firing is pretty clear evidence the sync is blocking the main isolate. It's the same pattern as #3898 but your report actually isolates it properly.No user-side workaround for this one, the fix has to come from the team. Worth opening it as a proper issue since you have solid evidence