Sign up
View stargazersSign up

[Bug]: Web and desktop offer no retry while an environment is reconnecting, and the wait grows to five minutes#22024

opened22d agobyJJacksondr5

Before submitting

I searched existing issues and did not find a duplicate. Closest: #11671 and #14897 (below), and #21709, which handles a refused login.

Area

apps/web

Steps to reproduce

  1. In the web or desktop app, pair a second environment and open one of its threads.
  2. Stop that environment's server, and leave it down for a minute or two so several attempts fail.
  3. Start the server again.

Expected behavior

A way to retry now. #14897 raised the backoff cap from 16 s to five minutes on the basis that "returning to the app, the network coming back, and an explicit retry still skip the wait", and docs/internals/connection-runtime.md says the same. The mobile app offers this: EnvironmentConnectionNotice shows "Retry now" while reconnecting.

Actual behavior

The chat view's banner says " is reconnecting" and has no Reconnect button: ChatView.tsx renders it only when !environmentReconnecting, so it appears for offline and failed connections only. #11671 removed the disabled "Reconnecting..." button here, when the cap was still 16 s. Settings › Connections shows "Reconnecting: " and has no retry action at all.

So once the server is back, the client keeps waiting for its next scheduled attempt, with nothing to press. In a repro on main, the seventh failed attempt scheduled the next one 71 s out. The server was back and answering /.well-known/t3/environment for 50 s before the client tried again; it then connected in 150 ms. The wait keeps growing to five minutes.

Impact

Minor bug or occasional failure

Version or commit

Reproduced on main at 325a7e2ae4 (2026-10-19), unmodified.

Environment

Web client in Chromium on Linux, with two local dev servers: one the client is paired with, and a second saved as a remote environment over a direct connection. The banner and supervisor code are shared, so desktop behaves the same way (not run).

Screenshots, recordings, or supporting files

Before (today's behavior) and after (the fix below), captured in our fork, where we made the fix. The "Today" column matches what main shows.

TodayWith the fix
Chat view while reconnecting
Settings › Connections menu while reconnecting

Today: the banner waits out its timer after the server is back.

https://github.com/user-attachments/assets/457b59d2-46af-4284-91ed-df0f437b3684

With the fix: Reconnect connects in 0.6 s and the banner clears.

https://github.com/user-attachments/assets/0674d220-13a0-4c82-b5ea-4713c7c3a55f

A small fix, if you want it (happy to open a PR):

  • Show the banner's Reconnect for every phase except a first connecting.
  • Add "Reconnect now" to a saved environment's menu in Settings › Connections while it is reconnecting.

Both call the existing environmentCatalog.retryNow, as mobile's button does. A failed connection, such as a refused login, is left alone: retrying can't fix it, and #21709's "Pair again" covers that case.

Workaround

From the code, not tried: hide the tab or window and show it again (the visibilitychange wakeup skips the wait), or switch the environment off and on in Settings › Connections.

Filed by Claude Opus 5.5 (Claude Code) for @Jacksondr5.

JJulius Marminge22d ago

Note

Grok responding on behalf of Julius.

Thanks for the careful repro. Current main matches what you describe.

In the chat banner, the Reconnect button only renders when the environment isn't reconnecting (apps/web/src/components/ChatView.tsx:2278-2304), so while it's reconnecting the only action is Disconnect. The Connections settings show "Reconnecting" with the error (apps/web/src/components/settings/ConnectionsSettings.tsx:1441-1443) and no retry action next to it. Mobile does show "Retry now" while reconnecting (apps/mobile/src/features/connection/EnvironmentConnectionNotice.tsx:90-94).

The five-minute cap relies on an explicit retry being able to skip the wait. docs/internals/connection-runtime.md lists foregrounding, an explicit retry, and an offline report as the ways to do that. #11671 removed a disabled "Reconnecting..." button when the cap was still 16 seconds, so it didn't account for a long wait. Switching windows or toggling the connection off and on gets around it, but neither is something you'd find on your own.

Accepting this as a small bug: web and desktop should offer the same retry while reconnecting that the design and the mobile app already assume.

BB-EtterDigital22d ago
Synced from GitHub

Seen on desktop as well (nightly 20261019.3360, Linux), with one more consequence that lives in the same banner.

The server came back after a restart of about 90 s. The window stayed on "is reconnecting" for two more minutes, and its only button was Disconnect server. The user pressed it. That switched the environment off and hid every thread from it.

The banner then said "is offline" and offered Reconnect, which did nothing. It calls environmentCatalog.retryNow, and EnvironmentSupervisor.retryNow only resets the backoff and sends RetryRequested. intent.desired stays false, so the run loop goes back to waiting. The threads came back only after the environment was switched on again outside the banner.

#22207 fixes the first part. Two small additions would close the trap:

  • On a switched-off environment, Reconnect calls setEnabled({ enabled: true }), or the banner offers "Switch on again" instead, so the button is never a no-op.
  • Disconnect server says what it does before it acts: the threads are hidden and come back from Settings › Connections. Today that is only in the button's title tooltip.

Code read at main 774c6c1953: ChatView.tsx (handleReconnectActiveEnvironment, disconnectAction) and client-runtime/src/connection/supervisor.ts (retryNow).

Written by Claude Opus 5.5 (Claude Code) for @B-EtterDigital.

JJulius Marminge20d ago

Reproduced in Chromium on Linux at 70e5e384da: paired two local dev servers, opened a saved thread from the second, then stopped that server. The chat banner showed “fs-38 is reconnecting” without a retry action. Settings now has “Retry now” under Details, so that part differs from the original report. Desktop was not run.

Reconnecting chat banner without retry