Session state stale after device sleep/resume — heartbeat mismatch causes premature SSE disconnect #17769

Description

After a device resumes from sleep (closing laptop lid, phone lock screen, browser tab backgrounded for extended period), the web UI often shows stale session state — messages may be missing, the session appears stuck, or the UI shows "Unable to retrieve session". The connection does recover eventually but the state is often inconsistent.

Root cause: server/client heartbeat mismatch

The server sends SSE heartbeats every 30 seconds (server.ts:692), but the client expects a heartbeat within 15 seconds (global-sdk.tsx:108 HEARTBEAT_TIMEOUT_MS = 15_000). During normal operation this works because regular events (message updates, status changes) reset the client timer. But during idle periods with no activity, the client will timeout and abort the SSE connection between heartbeats — causing unnecessary reconnection churn even without a sleep/resume event.

Reconnection after sleep/resume:

1. Device sleeps → SSE connection goes stale, TCP socket may be closed by OS
2. Device wakes → visibilitychange fires → client checks lastEventAt
3. Since lastEventAt is from before sleep, Date.now() - lastEventAt >> 15s → attempt?.abort() fires
4. SSE reconnect loop starts (250ms delay) → new connection → server sends server.connected
5. Client re-bootstraps all directories (sessions, messages) — this part works
6. But global state (config, providers, auth) is NOT re-fetched on reconnect — only directory-level data is refreshed via queue.push(directory)
7. Any session that was mid-stream (assistant generating a response) when sleep happened loses that streaming state — the partial message is frozen and no further deltas arrive

Additional issue: SDK SSE client has no max retry attempts by default

The SDK's createSseClient (serverSentEvents.gen.ts:225) only limits retries if sseMaxRetryAttempts is explicitly set. The global-sdk wrapper does not set this parameter — it uses its own reconnect loop (line 124-191) that wraps the SDK stream. However, if the SDK's internal retry loop gets stuck (e.g. server returns 502 repeatedly), the exponential backoff can reach 30s between attempts while the outer loop also waits 250ms — leading to confusing double-retry behavior.

Steps to reproduce

1. Open opencode serve web UI on a phone or laptop
2. Start a session and send a message
3. While the assistant is responding, lock the device / close the lid / switch tabs for 30+ seconds
4. Resume the device / reopen the tab
5. Observe: the assistant response may be frozen, or the session shows stale data

OpenCode version

1.2.26

Operating System

Any (macOS, iOS Safari, Android Chrome, Linux)

Terminal

N/A (web UI via opencode serve)