[Bug]: Server: config snapshot waits on editor, file manager and SSH target probes in sequence on every connect

[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/server

Steps to reproduce

1. Run a server on a loaded machine, where spawning processes and walking PATH are slow.
2. Connect a client. Every connect (and reconnect) calls server.getConfig / subscribeServerConfig, which is built by loadServerConfig in apps/server/src/ws.ts.

Expected behavior

The config snapshot a client waits on to connect does not wait on host discovery that has already succeeded recently, and independent discoveries do not add up.

Actual behavior

loadServerConfig runs editor discovery, then file-manager reveal discovery, then remote open target discovery (sshd and tailscale probes), one after another. Each has its own 5 second timeout (CONFIG_DISCOVERY_TIMEOUT), so the snapshot can wait up to 15 seconds on discovery alone, which is the client's whole connect budget. Editor discovery is cached for 60 seconds, but after expiry the next connect waits for a full rescan. File-manager and remote-target discovery are not cached at all and run on every connect.

During an incident on a loaded machine, editor PATH probing hit its 5 second timeout inside subscribeServerConfig while clients were timing out their connections.

Impact

Major degradation or frequent failure

Version or commit

upstream/main @ 0cf482b (apps/server/src/ws.ts loadServerConfig, apps/server/src/process/externalLauncher.ts, apps/server/src/environment/RemoteOpenTargets.ts).

Environment

macOS 26 (Darwin 25.5), background service, load average 30 to 40 at the time.

Logs or stack traces

Server trace spans inside subscribeServerConfig: resolveAvailableEditors ending at its 5 s timeout during the reconnect loop.

Workaround

None on the client side.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Triage

Thanks for the detailed report. I confirmed this on main at 0cf482b08bc. It's a stall on the connect path, separate from the empty Open menu in #4697 (closed).

The client's session.ready waits for the first subscribeServerConfig snapshot (packages/client-runtime/src/rpc/session.ts), and the supervisor gives up on setup after 15 seconds (CONNECTION_ESTABLISHMENT_TIMEOUT in packages/client-runtime/src/connection/supervisor.ts). The server builds that snapshot in loadServerConfig in apps/server/src/ws.ts, which awaits three discoveries one after another, each wrapped in the 5-second CONFIG_DISCOVERY_TIMEOUT:

1. externalLauncher.resolveAvailableEditors() is cached for 60 seconds, but only after a scan succeeds. A timeout or disconnect stores nothing, and concurrent connects don't share one scan, so a reconnect loop starts a fresh PATH scan on every connect.
2. resolveFileManagerRevealKind() runs only when that list contains "file-manager", and it isn't cached.
3. remoteOpenTargets.resolveTargets() isn't cached either. It runs on every server.getConfig and every config subscription, since both go through the same loadServerConfig.

The "up to 15 seconds" figure is the three timeouts added together, which is the client's entire setup budget. On a macOS host like yours they don't quite stack that way. If the editor scan times out, the fallback is [], so the file-manager probe never starts (on darwin it would just return "finder" with no I/O). Remote targets return right away when nothing listens on port 22. When sshd is up, tailscale status has its own 1.5-second timeout and the loopback checks use a 250ms socket timeout, so the 5-second wrapper is only a backstop.

A timed-out editor scan doesn't use the full 15 seconds by itself, but it eats into that budget, and the uncached remote-target probe and the rest of config loading have to finish in whatever time is left. With a load average of 30–40, that fits clients dying in the reconnect loop while resolveAvailableEditors hits its 5-second timeout. Because an interrupted scan isn't cached, every retry pays for it again.

#13669 (merged, for #4697) made editor discovery list PATH directories instead of stat-ing every candidate, so a scan on an idle machine usually finishes well under 5 seconds. It didn't move discovery off this snapshot, though, and a scan that loses the race is still thrown away. #13917 (open PR) lets the scan finish in the background and republishes editors later. Even with that change, the first snapshot still waits on editor discovery, then the file-manager reveal, then remote targets, and the last two still aren't cached.

The direction for a fix: the first config snapshot shouldn't wait on host discovery that has nothing to do with auth or settings, and a connect timeout shouldn't be the thing that throws the scan away.