[Bug]: Client: a slow first config snapshot makes clients drop working connections and reconnect-loop

[saphid]

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. Connect a client (desktop, web or mobile; the logic is in packages/client-runtime) to a server that is slow to build its first config snapshot. In my case this was a server restarted cold with a 32.8 GB database on a loaded machine, where synchronous SQLite reads made subscribeServerConfig take longer than 15 seconds.
2. Watch the connection.

Expected behavior

Once the websocket is open and the server is answering, the client waits for the first config snapshot instead of dropping the connection.

Actual behavior

EnvironmentSupervisor gives each attempt one 15 second budget (CONNECTION_ESTABLISHMENT_TIMEOUT) that covers credentials, session creation, the socket open, and the first config snapshot. When the snapshot alone takes longer, the attempt times out, the working socket is torn down, and the client retries with backoff. The server is no faster on the next attempt, so the client loops: connect, socket up, timeout, retry. In my traces ConnectionDriver.connect was interrupted on every attempt for about 10 minutes, until the server warmed up.

Impact

Blocks work completely

Version or commit

Seen on a 0.0.42 nightly desktop build; packages/client-runtime/src/connection/supervisor.ts is unchanged on upstream/main @ 0cf482b.

Environment

macOS 26 (Darwin 25.5), desktop app connected to a local background service.

Logs or stack traces

Client traces (ConnectionDriver.connect spans) showed status.interrupted: true for each attempt; server traces showed subscribeServerConfig and the discovery spans inside it (resolveAvailableEditors at its 5 s timeout, ServerSecretStore.get 8 s, a trivial reportClientActivity 9.8 s) while the event loop was blocked.

Workaround

Wait for the server to warm up, or restart it when the machine is less loaded.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Triage

Confirmed on main (0cf482b08bc). The reconnect loop is in the shared client, not the desktop shell, and it's still there.

EnvironmentSupervisor races each connect attempt against one 15-second budget (CONNECTION_ESTABLISHMENT_TIMEOUT in packages/client-runtime/src/connection/supervisor.ts). The attempt is ConnectionDriver.connect, which only returns at session.ready. ready waits for the socket to open and for the first subscribeServerConfig snapshot (packages/client-runtime/src/rpc/session.ts). If the budget runs out first, the supervisor records a timeout, drops the lease (and the open socket with it), and retries after 3s, 4s, 8s, then 16s. A test in packages/client-runtime/src/connection/supervisor.test.ts ("retries when a session never becomes ready") expects exactly this: a session already in synchronizing gets torn down at 15 seconds.

So a server that's slow but still building the snapshot never gets to finish it. Every retry starts subscribeServerConfig from scratch, which explains the connect, timeout, retry loop until the process warms up. The budget also starts before credentials and the socket open, so once the socket is up, a slow snapshot has less than 15 seconds left.

This is a different path from open issue #7231, where a foreground health probe tears down a session that's already connected. It's also different from closed PR #5561, which dealt with pong timeouts after the socket is up and with caching editor discovery. Both of those only run after ready succeeds. Editor discovery inside the snapshot is already capped at 5 seconds and memoized, so it isn't what uses up the whole budget. The long ServerSecretStore.get and reportClientActivity spans fit the event loop being blocked while that first snapshot is in flight.

The client should keep a socket that's open and still receiving the first snapshot, instead of counting that wait against the setup deadline. A server that never answers still needs some limit, though, so an open socket with a dead handler doesn't sit on "connecting" forever.

The 32.8 GB database is why the snapshot missed the deadline. Synchronous SQLite blocking the event loop is a separate server problem (the server-side discovery part is tracked in #14517). The loop itself comes from this client deadline.