Repository navigation
[Bug]: Desktop relay environment takes 15–27 s to reconnect after macOS wake #25273
Closed as not planned
Description
Setup: macOS desktop, T3 Code 0.1.3-nightly.20261023.3553, remote environment connected via T3 Connect relay (RelayConnectionTarget). The same machine is reachable over plain SSH instantly after wake.
Observed (time from macOS wake to first successful RPC to the remote env): 8 s, 15 s, 13 s, 27 s across recent wakes. The local env is ready in ~14 ms.
In the 27 s case: Wakeup signal at +0.2 s → state change at exactly +15.0 s (establishment timeout) → backoff retries → connected at +27 s. RPCs in between fail with EnvironmentRpcUnavailableError: <env> is not connected.
Why (from packages/client-runtime/src/connection/supervisor.ts):
waitForEstablishmentInterruptignoresWakeup(application-active),Wakeup(network-changed)andNetworkChanged(online). An attempt started right at wake (before Wi-Fi is fully back) can't be aborted and must hitestablishmentTimeout(15 s × routes).- The retry is fired immediately on
visibilitychange, ~0.2 s after wake, likely before the network path is usable. - Electron
powerMonitorresume/unlock-screenevents are only used byDesktopTelemetryPublisher; they don't feedConnectionWakeups. Mobile hasapplication-active-reconnect(see [Bug]: iOS relay resume repeatedly waits on reconnection; Paseo comparison and recovery references #16418); desktop has no equivalent.
Suggestions:
- On resume/unlock, emit an
application-active-reconnect-style wakeup so a stale session/attempt is dropped and restarted (as mobile does). - Let
NetworkChanged(online)/network-changedinterrupt an in-flight attempt that started before the change, with retry reset. - Or hedge: if an attempt reports no progress within ~3 s after wake, start a parallel attempt instead of waiting the full 15 s.
Activity
juliusmarminge commentedon Nov 12, 2026
I tried to reproduce this on the current build and could not.
A real run is not possible here: it needs a macOS desktop sleeping and waking while connected to a remote environment through T3 Connect, and the workers have neither T3 Connect nor macOS sleep. Instead, on origin/main 71e1f2a, I added a test to packages/client-runtime/src/connection/supervisor.test.ts, "restarts a stalled relay attempt when the network path changes". It starts a relay-only environment whose first connection attempt never finishes, then sends a network-changed wakeup and advances the test clock 1 s. On main the test fails with 1 connection attempt instead of 2, and the supervisor stays connecting until the 15 s establishment timeout, as the reporter saw. The test pushed is in commit 2b52024. As a check, I temporarily let waitForEstablishmentInterrupt treat network-changed the way it treats application-active-long. The new test and all 69 tests in the file then passed, and I reverted that change. Code reading confirms the other half of the report. On the desktop, Electron powerMonitor resume and unlock-screen are only consumed by DesktopTelemetryPublisher. The web platform only sends application-active (on visibilitychange) and network-changed, and the supervisor ignores both while a connection attempt is in flight.
Closing as not planned. If it still happens for you, reply with the exact steps and the version you are on and it will be looked at again.