[Bug]: A connection switched off as unsupported stays blocked after the host is updated to V2 directly

[dev-ankit]

Area

packages/client-runtime (connections), surfaced in apps/web Settings → Connections

Summary

If a v2 client disables a saved direct connection because the host was still on v1, the connection stays disabled after the host is updated to v2 some other way. The switch is disabled ("Client not supported"). The only action left is Update, which fails against a host that is already on v2.

Steps to reproduce

1. Save a direct (non-relay) connection from a Nightly desktop client to a remote host, here a Windows desktop reached over a Tailscale IP.
2. Update the client to a v2 Nightly while the host is still on v1. The client marks the environment unsupported (serverUpdateRequired) and switches it off.
3. Update the host to the same v2 Nightly yourself on that machine, not through the client's Update button.
4. On the client, open Settings → Connections.

Expected behavior

The client sees that the host now speaks orchestration protocol 2, clears the block and lets the connection be switched back on. Pressing Update when the host is already compatible should do the same.

Actual behavior

• The switch stays disabled, and nothing clears the block. unsupportedReason is only cleared by relay discovery (connection/layer.ts, relay targets only) or by a successful updateOutdatedHost. A disabled direct connection never runs a socket handshake, so it never checks again.
• Pressing Update calls updateOutdatedHost. That gets its socket URL from resolver.prepareForUpdate (= authorize), which does not call appendOrchestrationProtocol, and it never checks whether the descriptor it just fetched is already compatible. The v2 host rejects the bare socket with 426 orchestration_protocol_incompatible, so the update fails.
• The UI shows Client not supported and SocketOpenError: An error occurred during Open during update

Impact

Blocks work completely for that connection until the client restarts. It will likely affect anyone who updates their machines one at a time during the move to V2 (#14871).

Version or commit

Nightly 0.0.46-nightly.20261003.2638 (5e35272) on both sides. packages/client-runtime/src/connection/ has not changed on main since then.

Environment

Client: macOS desktop Nightly. Host: Windows 11 desktop Nightly (NT 10.0.26200, x64), direct connection over Tailscale.

Logs

Host server.trace.ndjson, requests from the macOS client (user agent T3Code(Nightly)/0.0.46-nightly.20261003.2638). The descriptor and ticket requests succeed, then the socket is rejected:

http.server GET  /.well-known/t3/environment   status=200
http.server POST /api/auth/websocket-ticket    status=200
http.server GET  /ws                           status=426

apps/server/src/ws.ts returns 426 only when the orchestrationProtocol query param is missing or wrong.

Possible fix

In updateOutdatedHost, if the descriptor from prepareForUpdate already passes isCompatibleDescriptor, skip the self-update RPCs and go straight to the resume step: clear compatibility and re-enable.

Workaround

Confirmed: restart the client, then switch the connection back on in Settings → Connections. This works because unsupportedReason is held in memory and only enabled: false is persisted.

---

Investigated with Claude Code (Claude Opus 5.5).

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Triage

Thanks for the detailed report and for confirming the workaround, @dev-ankit. This is a real bug on main at 88744f3ddb, and packages/client-runtime/src/connection/ hasn't changed since the nightly you cited (5e35272fda).

What's happening

When the host rejects the client's protocol, the client keeps unsupportedReason and serverUpdateRequired only in memory, sets enabled: false, and saves that switch state. Settings then shows Client not supported, disables the switch, and offers Update.

After that, nothing checks a direct connection again. watchDiscoveredCompatibility in packages/client-runtime/src/connection/layer.ts only applies discovery results to a RelayConnectionTarget. A disabled entry never connects, because createServiceScope only calls supervisor.connect when enabled is true. setEnabled(true) also refuses while unsupportedReason is set, so the block lasts until the client restarts.

Update can't clear the block once the host is already on protocol 2. updateOutdatedHost gets its socket from prepareForUpdate, which is authorize. That fetches the descriptor but doesn't append orchestrationProtocol, and nothing checks the descriptor with isCompatibleDescriptor before the socket opens. A v2 /ws route returns 426 unless the request has orchestrationProtocol=2 (hasCompatibleOrchestrationProtocol). So the open fails with SocketOpenError: An error occurred during Open, and the resume step that would call setCompatibility(null) and setEnabled(true) never runs.

Related, but not the same bug

• #15051, with open PR #15052, covers relay connections. There, discovery can clear the in-memory reason, but the saved switch stays off, so the row shows Off. A direct connection never gets that discovery check.
• Draft #15107 would let a saved direct URL connection like this Tailscale one be switched back on and retried through the normal handshake. That recovers the row without a restart, but it doesn't change updateOutdatedHost, so Update would still open the socket without the protocol parameter and still fail.

Workaround

As you confirmed, restarting the client clears unsupportedReason. Only enabled: false is saved, so the row comes back as Off and you can switch it back on. Removing the connection and adding it again should also clear it without a restart.

Likely fix area

One option is in updateOutdatedHost: after prepareForUpdate, if isCompatibleDescriptor(descriptor) is true, skip the socket and the self-update RPCs and go straight to the existing resume step. For a relay target, that step runs discovery.refresh before clearing, then calls setCompatibility(null) and setEnabled(true). The 426 check on v2 should probably stay, since updating a v1 host depends on opening /ws with no protocol parameter.

A test in outdatedHostUpdate.test.ts could serve a protocol-2 descriptor from prepareForUpdate, assert the websocket is never constructed, and assert the calls are clear and then enable.

A maintainer will decide on the fix direction.