When the Host Is Not Ideal: Reconnection, Updates, and Failure

A remote control surface is judged most honestly when the connection is imperfect. This chapter diagnoses the failures that appear when a client reconnects late, a server continues without a browser, an update interrupts work, or a provider is missing or incompatible. The practical goal is to separate transport failure from stale data, client/server version skew from provider failure, and background service exposure from T3 Connect exposure. T3 Code can make these states understandable, but it cannot make an unavailable host or a provider-specific limitation disappear.

A connected socket can still show stale work

The first misleading symptom is “the app is connected, so everything must be current.” T3 Code’s shared connection runtime separates transport health from data freshness. The web client, desktop renderer, and mobile client share a connection owner for an environment, and a supervisor manages transport retries. But a socket opening is only the beginning. The runtime waits for initial environment configuration, and thread or shell subscriptions have their own synchronization state.

A client can therefore be in several different situations. The transport may be down and no current data can arrive. The transport may be open while a thread detail subscription is still catching up. Cached projections may be readable even though they are not live. A shell stream may be stale while another part of the environment connection is healthy. Reporting all of these as a single “reconnecting” state would promise a retry that may not address the actual problem.

stateDiagram-v2 [*] --> Available Available --> ClientDisconnected: client backgrounds or network drops ClientDisconnected --> Reconnecting: foreground or retry wakeup Reconnecting --> ConnectedFresh: session and subscriptions ready Reconnecting --> StaleData: transport open, data not current StaleData --> ConnectedFresh: subscription catches up Available --> OfflineHost: host stops or becomes unreachable OfflineHost --> Available: host returns Available --> UpdatePending: server update requested UpdatePending --> VersionRefused: protocol versions differ VersionRefused --> Available: compatible side updated Available --> ProviderIssue: provider missing or incompatible ProviderIssue --> FreshProviderSession: setup or recovery succeeds

The recovery path follows the symptom. A client coming back from a long mobile suspension may need a new session because the operating system can kill the old socket without reporting it. A foreground action can wake a pending retry or probe an established session rather than opening competing reconnect loops. An authentication failure should wait for a credential change or explicit wakeup rather than spending attempts against an unchanged condition.

Cached data is useful, but only if it is labeled as cached. The connection runtime retains projections and replay cursors so back navigation and reconnection do not always require a full snapshot download. It also prevents an old scope from overwriting a newer one. This makes the UI more responsive without making offline state authoritative. A user can read the last known thread, but a new mutation still needs a valid environment session and its own retry or idempotency rule.

The same distinction matters when a client says that an environment is offline. An offline report may be wrong for a loopback server or a route that the operating system temporarily misclassified. The client can probe the established session and reconnect only when the probe fails, while a long background suspension justifies replacing the session immediately.