[Bug]: Mobile cannot connect to online relays after updating to 0.0.32-nightly.20260730.958

[tradesdontlie]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

This looks related to #4671 and #4901, but those reports cover direct LAN/Tailscale connections and explicitly say the managed relay was not involved. This report is specifically for mobile connections through online T3 Connect relays.

Area

Not sure (mobile / managed relay connection boundary)

Steps to reproduce

1. Update T3 Code Desktop Nightly to 0.0.32-nightly.20260730.958.
2. Leave the existing T3 Connect relay environments enabled.
3. Confirm the relay entries are still online.
4. Open the T3 Code mobile app and try to connect to either linked environment.
5. Observe the mobile connection status.

Expected behavior

Because the relays are online and enabled, the mobile app should connect to each linked environment normally.

Actual behavior

The relays remain online, but the mobile app cannot connect to them. Each entry repeatedly shows a reconnect loop.

The visible errors are:

Failed to connect. Reconnecting... Reason: TDL connection failed unexpectedly.

and the same failure for Andrew's Mac Studio.

This began after updating to 0.0.32-nightly.20260730.958; the relay connection worked on mobile before the update.

Impact

Major degradation or frequent failure

Mobile access through T3 Connect is unusable even though the relay environments themselves remain online.

Version or commit

0.0.32-nightly.20260730.958

Environment

• T3 Code Desktop Nightly
• Host environment shown in the mobile UI: Andrew's Mac Studio
• T3 Code mobile app (mobile OS/app version not captured)
• Connection path: T3 Connect managed relay
• Multiple linked environments affected (TDL and Andrew's Mac Studio)

Logs or stack traces

Failed to connect. Reconnecting... Reason: TDL connection failed unexpectedly.
Failed to connect. Reconnecting... Reason: Andrew's Mac Studio connection failed unexpectedly.

Screenshots, recordings, or supporting files

A screenshot is available showing both relay entries enabled and simultaneously stuck in the reconnect loop. It could not be attached through the API-based submission.

Workaround

No workaround found.

[ugurkocde]

Same Issue on two devices.

Trace ID: 1c3d22c5b1f2f1e77db40e8ea289cf3b

[kdegeek]

Same issue on tailnet connections

[MrDocProfPj]

I’m seeing a distinct earlier-stage failure on macOS Nightly/iOS. The mobile client fails fetching /.well-known/t3/environment, before WebSocket authentication or server.getConfig.

Independent test: DNS resolves, TCP 443 connects, the TLS ClientHello is sent, but no ServerHello arrives and the connection times out. HTTP port 80 responds 204 through nginx/Heroku. Both local endpoints on port 3773 return 200, and the local cloudflared tunnel is running.

Trace ID: b25673c0cf4b8facc0bb33463735154d

This differs from #4901, which connects successfully and disconnects after server.getConfig.

[hashmil]

Correction to my earlier comment: .953 is good, and the regression is earlier than .958.

I previously said downgrading didn't help — but I'd only gone back to .957. Rolling my Linux environment (t3 serve under systemd) to 0.0.32-nightly.20260730.953 fixes it completely.

The failure is at the upgrade handshake: GET /ws is answered 204 instead of 101 Switching Protocols.

POST /api/auth/websocket-ticket   → 200
GET  /ws                          → 204     ← expected 101

That repeats every ~10–17s and produces Failed to connect. Reconnecting… Reason: <environment> connection failed unexpectedly. It is not mobile-specific — the web client at app.t3.codes fails identically.

Broken: .963, .961, .957 · Good: .953

So the regression window is .954–.957, not .958 as the title suggests.

Same host, same account, same state.sqlite — only the version changed:

	.963 (broken)	.953 (good)
GET /ws	3 × 204 in 55s	none logged — upgrade succeeds, so it becomes a persistent connection and never logs a response
websocket-ticket	re-requested on every retry	quiet after connect
cloudflared → node ESTAB on 127.0.0.1:3773	torn down every ~17s	4 held stable for 3+ min
app traffic	none	/api/orchestration/threads, /api/orchestration/shell at 200

Happy to bisect .954–.957 to pin down the exact build if that would help.

[hashmil]

Follow-up with a further narrowing, and one result that complicates my previous comment.

The .953 fix is specific to headless t3 serve. The macOS desktop app is not fixed by it.

I rolled the macOS desktop app back to 0.0.32-nightly.20260730.953 — the exact build that fixes my Linux environment — and GET /ws still returns 204:

14:05:43  /ws → 204
14:06:01  /ws → 204
14:06:19  /ws → 204
…every ~18s

So on my two environments:

Environment	Packaging	.953	.957	.963
Arch Linux, t3 serve under systemd	npm	works	broken	broken
macOS, desktop app (Apple Silicon)	DMG	broken	broken	broken

The macOS desktop app returns 204 on every build I have tried. That suggests either a desktop-app-specific path, or a second failure mode distinct from the one .953 avoids — which may be what @MrDocProfPj is seeing, since that report is also macOS Nightly and fails at an earlier stage.

Regression window for the headless case: .954–.957 (21 commits, v0.0.32-nightly.20260730.953...v0.0.32-nightly.20260730.957).

The only commit in that range touching connect/relay is #4988 (fix(connect): reboots no longer strand the relay link, 403s now say why, 1877237c), which modifies:

infra/relay/src/environments/EnvironmentConnector.ts   +3/-15
infra/relay/src/http/Api.ts                            +4/-2
packages/contracts/src/relay.ts                        +19/-1

I want to be clear that this is unconfirmed — the visible diff is largely a refactor moving EnvironmentConnectNotAuthorizedReason into @t3tools/contracts/relay. But it is the only change in the window that touches both the relay service and the shared environment/relay contract, which would fit a failure that (a) manifests on the hosted side and (b) is avoided by pinning the environment to .953.

Others in the window that touch reconnect behaviour, for completeness: #4878 (perf(mobile): reconnect environments immediately on resume), #4903 (fix(web): show server update progress through reconnect), #4731 (fix(web): align remote server update action).

Happy to bisect the .954–.956 builds on the Linux environment to pin the exact release if that would help.

[hashmil]

Correction to my two earlier comments: the 204 is a red herring. Please don't chase the status code.

I described this as GET /ws returning 204 instead of 101 Switching Protocols. That framing is wrong, and I'd rather correct it than have anyone spend time on it.

204 is simply what this server logs when a WebSocket session ends. Healthy sessions log 204 too. The real signal is the span duration — how long the connection survived.

From one environment's log, spanning a broken build and a working one, with no other changes:

# broken (0.0.32-nightly.20260731.963) — reconnect loop, one attempt every ~18s
12:20:27  /ws  span=514ms
12:20:45  /ws  span=524ms
12:21:03  /ws  span=506ms
…identical every 18s for the whole period…
12:29:37  /ws  span=530ms

# after rolling back to 0.0.32-nightly.20260730.953 — sessions persist
12:40:21  /ws  span=129868ms      (2m)
14:08:43  /ws  span=5808849ms     (1h 37m)
14:10:36  /ws  span=84476ms       (1m 24s)
14:11:42  /ws  span=5995852ms     (1h 40m)
14:15:18  /ws  span=262724ms      (4m 23s)

So the accurate description is: the WebSocket is established and then torn down after roughly 500 ms, and the client retries every ~18 s. It is a connection-lifetime problem, not a failed upgrade. Everything before it — DNS, the cloudflared tunnel, /.well-known/t3/environment, /oauth/token, /api/auth/websocket-ticket — succeeds, which I still believe is accurate.

That ~500 ms is suspiciously consistent, which suggests a fixed timeout or a failed post-connect step (first heartbeat, auth confirmation, or an initial RPC) rather than a network fault. That may connect this to #4901, where the session dies after server.getConfig.

The rest of my earlier comments stands: .953 fixes the headless t3 serve case, and the regression window is .954–.957.

Apologies for the noise — the 204 reading was mine, not something the logs actually claimed.

[NikAtNight]

Additional investigation confirms that #5055 fixes the ServerConfig compatibility problem only for clients built after that PR. Its description explicitly says already-shipped 0.0.31 clients require a new store build, so merging #5055 does not restore connectivity for the current iOS/Android apps.

I also found failed WebSocket attempts that closed before server.getConfig was dispatched. Those cannot be caused or fixed by #5055, suggesting there may be a second connection-lifecycle failure in addition to the confirmed config-decoding problem.

Could a maintainer clarify:

1. Which mobile release will contain fix(contracts): decode growing config unions forward-compatibly #5055?
2. Whether a temporary server-side compatibility measure is planned for currently released clients?
3. Whether the pre-server.getConfig closures should be tracked separately?

[MrDocProfPj]

Follow-up/correction on my macOS/iOS case after updating both clients. The new screenshots showed:

• Managed endpoint health request failed. — trace cbd248f5e4a95cfe2e46104f29649d30
• Relay environment endpoint is unavailable: endpoint_request_failed — traces 0c00216f88bdc59015a669a70ae5ea1d and a507a068d359dcaa53eae33a1d29f7dd

However, the local evidence now points to my Wi-Fi security layer rather than a T3 origin/tunnel failure:

• Desktop Nightly is 0.0.32-nightly.20260801.969.
• The server is listening on 0.0.0.0:3773; loopback and LAN requests return 200.
• cloudflared has four active HA connections and zero origin/proxy errors.
• After the tunnel finished reallocating, hosted relay requests reached this Mac successfully: /api/t3-connect/mint-credential returned 200 four times and /api/t3-connect/health returned 200 twice.
• My normal network resolver substitutes the generated managed hostname with 18.204.152.241; DNS-over-HTTPS returns the expected Cloudflare addresses instead. HTTPS to the substituted address stalls after ClientHello. This network uses Plume/HomePass Online Protection, whose HTTPS blocking behavior is a generic “cannot reach”/TLS failure.

So my earlier “no ServerHello” observation was real, but it was against the security layer’s substituted address—not proof that T3’s managed TLS frontend was down. The screenshot failures at 21:40 also coincided with the desktop update/tunnel restart; managed health and credential minting succeeded immediately afterward.

I am confirming over iPhone cellular and will report back only if the failure persists off this Wi-Fi. This may be useful for support/docs: users of Plume/HomePass-style network protection may need to approve t3coderelay.com (including generated subdomains).

[eeinarsson]

Additional diagnostics from Windows after updating Desktop Nightly to
0.0.32-nightly.20260801.970.

Android app: Play Store 0.1.0.

Initially, mobile reported:

Managed endpoint health request failed.

I found an orphaned cloudflared.exe process after closing T3 Code. After terminating it and reopening T3 Code:

• The backend correctly started on 127.0.0.1:3773.
• cloudflared established 4 edge connections.
• Tunnel metrics showed 18 requests and 0 origin errors.
• Mobile changed back to connection failed unexpectedly.

The fresh desktop traces show two connection attempts at approximately
14:59 CEST on August 1:

1. WebSocket ticket request succeeds.
2. WebSocket authentication succeeds.
3. SessionStore.markConnected succeeds.
4. ws.rpc.server.getConfig succeeds in approximately 3.1 seconds.
5. The client disconnects roughly 100–150 ms afterward.

Server trace IDs:

• fd32bf59fee5ace844d09d18130fa359
• 0ca92d77090d9b062e2763a8279ee752

This appears consistent with the Android 0.1.0 client failing to process the
configuration returned by the newer server. Since #5055 changes client-side
decoding, it appears that a new Android store build containing that change is
still required.

The orphaned tunnel process was a separate issue; after clearing it, the
managed relay and WebSocket path are healthy up to server.getConfig.