feat(desktop): auto-reload stale renderer when the user is away

[wpfleger96]

Summary

Long-lived Buzz desktop renderer sessions accumulate heap and timer churn until GC pauses queue behind input, degrading scroll and click latency (the multi-GB, multi-hour sessions that motivate this). The Cmd+R clean-teardown reload clears it without touching the native engine or its child agents — but relies on the user noticing the degradation and acting.

This adds an idle backstop that performs the same clean-teardown reload automatically, but only when the user is provably away and the session is old enough to have accumulated the churn — never during use.

How it decides

The backstop arms once the renderer session is ~12h old, then checks once a minute. It reloads only when all of these hold:

• Session age >= 12h
• Window unfocused
• OS idle >= 30 min (unknown/unsupported idle API → never fire)
• No volatile, reload-destroyed work outstanding

Volatile-work registry

Everything a reload would destroy is tracked through one app-global registry (volatileWorkRegistry.ts) that owns acquire/release and exposes a single hasVolatileWork() the policy reads. The registry is the sole blocker surface, covering:

• A starting or active Huddle
• A foreground or background media upload, including the isCompleting/onComplete settling window
• Queued local File attachments a draft cannot serialize
• Any in-flight send/mutation/native operation (queryClient.isMutating() — sends, install/import/save all run as mutations)
• The native multi-file picker, held across the whole open-dialog-plus-upload operation

The native picker registers at the choke point via one withVolatileWork(label, run) helper in tauriMedia.ts, so every caller of pickAndUploadMedia is covered by construction and the acquire/release is balanced on both resolve and reject — no caller can forget to register, and no path can leak a key. pickAndUploadMedia lives beside its sibling pickAndUploadImage in tauriMedia.ts and is re-exported from tauri.ts, so existing @/shared/api/tauri imports are unchanged.

Draft text survives a reload — persisted drafts sit in localStorage, and text typed since the last persist is flushed synchronously on pagehide (see below) — so draft text is deliberately not a blocker.

Why the paperclip's own dialog is left unregistered

The deferred paperclip path (handlePaperclip when queueUntilSend) opens useFilePicker's hidden <input type="file"> rather than the native picker, and it is deliberately not registered with the registry:

• No reload-destroyed state exists until change fires. useFilePicker's own comment records that "Cancel emits no change" — cancelling the dialog discards everything, and a change routes straight into queueFiles/uploadFiles, which are already covered by the registered queuedAttachments/uploadingCount hold.
• A user interacting with an open dialog is not OS-idle, so the 30-minute idle gate cannot fire mid-dialog anyway.
• The alternative is strictly worse. Acquiring on open has no reliable release signal (there is no cancel event in this webview), so a leaked key would block the backstop forever — converting a benign, already-covered gap into a permanent reload-blocker.

Reload primitive

Cmd+R and the backstop now share one idempotent requestRendererReload():

• A module-level in-flight promise collapses overlapping triggers (a second Cmd+R, or the backstop firing mid-teardown) so the native WebSocket teardown never runs twice.
• Teardown is bounded to RELOAD_TEARDOWN_TIMEOUT_MS (500 ms); a hung socket loses to the timeout.
• A rejecting teardown is logged and swallowed, and the reload always runs in a finally — a rejection can no longer win the Promise.race and strand the renderer on a stale heap (the pre-existing Cmd+R bug this replaces).

Composer flush on reload

Live composer editor text was persisted to localStorage only on the draft-key-change effect cleanup in useDraftPersistSnapshot.ts, and location.reload() does not run React effect cleanup — so text typed-but-not-yet-persisted would be lost on any reload (backstop, Cmd+R, or window close). useDraftPersistLifecycle now registers a pagehide listener that flushes the current draft synchronously, mirroring the precedent in useObservedUnreadPersistence.ts. The persist logic is factored into one persistDraftSnapshot(key, channelId) helper so the key-change cleanup and the pagehide flush share a single write path — the cleanup persists the outgoing draft, the flush persists the current one, from the same live editor content. This closes the reload-destroyed-text gap for all three reload paths in one mechanism.

Structure

• All fire/withhold logic is a pure, exhaustively tested predicate (idleAutoReloadPolicy.ts); the hook (useIdleAutoReload.ts) only wires live signals, arms after the session-age threshold, and serializes overlapping checks.
• Every signal is read imperatively at check time (once a minute), so the hook holds no reactive subscription and never re-renders the app tree.
• The controller mounts inside the ready main-window shell only, guarded by huddleWindowChannelId() === null — so Huddle companion windows and every onboarding/blocking/reset/keyring/relaunch screen are ineligible by construction, and isMutating() reads the message-send query client.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

BLOCKING: REQUEST CHANGES

Reviewed exact head ac3c3d6c62897f643b65f450efbecf10571ca948 against base bbd20fae75ecc3bd7a83cc12a65379fac22a2b79 by source inspection only.

[P1] The volatile-work closed set still permits idle reload to erase unsent drafts

The feature contract says a reload fires only when no reload-destroyed work exists, but two ready-shell surfaces retain unsent state solely in renderer memory without registering it:

1. Completed forum attachments. ForumComposer registers only nonblank text (desktop/src/features/forum/ui/ForumComposer.tsx:59-64), while useMediaUpload registers only active uploads or queued local files (desktop/src/features/messages/lib/useMediaUpload.ts:901-916). After an immediate upload completes, an attachment-only forum post/reply/note/issue/PR-comment remains in pendingImeta, but every reload blocker is false. On an old session, leaving the app unfocused for the idle threshold reloads and discards that draft.
2. Send Feedback drafts. The dialog’s message/category/log selection (desktop/src/features/settings/ui/SendFeedbackDialog.tsx:91-107) and completed attachment descriptor (desktop/src/features/settings/hooks/useSendFeedback.ts:49-71) are neither persisted nor registered. queryClient.isMutating() protects submission, and the picker wrapper protects only the picker/upload operation; once either settles, an open unsent feedback draft can be erased by the same idle reload.

Please make every non-persisted draft state hold the volatile-work registry until it is submitted, explicitly discarded, or unmounted/closed, and add lifecycle tests for completed attachment-only forum drafts and populated Send Feedback drafts. The existing wiring tests cover in-flight/deferred uploads but do not cover these settled in-memory states.

No PR code was checked out or executed.