Session Reconnect

AppOrchestrator puts a busy prompt up on ConversationInterrupted — ReconnectingPrompt, presented as ReconnectingPopupContent: a spinner, "Connection interrupted", "Reconnecting you to the conversation…", and one full-width destructive button. It comes down on ConversationResumed, on ConversationLost, and on any interaction-state transition, so no flow can leave it behind.

The button abandons the reconnect, and abandoning is an ordinary exit: ExitInteractionAsync runs, EndConversationAsync cancels the resume on the way out, and no lost-conversation report follows — the user made that call themselves, so telling them the conversation ended would be reporting their own decision back at them. The report is reserved for the reconnect running out on its own.

The notice is only shown while the interaction is Active. The reconnect itself runs regardless; there is just nobody to show it to otherwise.

A resume in flight is cancelled by EndConversationAsync and by CreateConversationAsync — the user left, or started something else, and the conversation being reconnected to is not wanted any more. Cancellation is also linked to the manager’s own destruction.

The awkward case is cancellation while a socket is already opening. CreateSessionAsync cannot be dropped mid-flight without leaving a live session behind, so the resume lets it finish and then ends it explicitly. Until it does, that session is a second session the app does not want, which is why EngineAPI.OnElementReceived and OnDisconnected both carry the Session they came from and ConversationManager ignores anything that is not _session. Without that filter a discarded session’s teardown would run the teardown of the live one.

ConversationManager.CheckNetworkPath polls Application.internetReachability twice a second while a session is live and drops the session through EngineAPI.DropSession — a close with no #end, so it takes the ordinary unintentional-disconnect path and resumes — as soon as the path is not the one the session was opened on. The path is captured by CaptureNetworkPath both when a conversation is created and when a resume lands, so each session is judged against its own.

It compares against the captured value rather than testing for NotReachable, because losing the path is not the same as losing connectivity. A socket opened over Wi-Fi is just as dead when the device falls back to cellular and stays online, and on iOS that is the more common shape of the failure.

This exists because the OS is the only party that knows. See A stalled socket is only noticed on Android, and websocket pings do not fix it for why the engine’s own timer is too slow to matter and why the socket itself says nothing: on iOS a socket whose interface disappeared stays open and silent, so with an 85 s detection latency against the engine’s 30 s abandon window, a dropped Wi-Fi connection is unrecoverable by the time anything else notices. Android errors the socket within a second on its own, and the poll simply races it there — either way the outcome is the same disconnect.

A path that flaps will now cost a reconnect rather than being ridden out. That is the intended trade: the socket did not survive the change, so riding it out was never really an option, and ReachabilityCheckIntervalSeconds is the knob if the noise turns out to matter.

SocketManager.EmitError and IManager.EmitEvent deliver to Namespaces["/"] only. The app opens the /socket/io/pipeline namespace and never asks for the root one, so every manager-level failure — transport error, connection timeout, connect_error, connect_timeout — is dropped on the floor. The Disconnect event is no help either: Socket.Disconnect dispatches it only if (IsOpen), and a namespace that never connected is not open.

The consequence was that CreateSessionAsync had three ways to complete and a failed connect triggered none of them, so the task stayed pending forever: the resume loop never took its second attempt and never checked its own deadline, and the reconnecting popup had no exit.

watchConnectFailureAsync closes that hole. It polls until either the connect timeout elapses or the manager puts itself in States.Closed — with Reconnection off, a manager that closed itself has given up — and fails the session through the same failSession path everything else uses. Opening the root namespace to listen for the real events would be the tidier fix on paper, but it makes the client send a namespace-connect for / that the engine has no handler for, and the refusal that comes back is indistinguishable from a real failure.

The watchdog stops the moment the socket connects, and this is the part to keep hold of when tuning the timeouts. Everything it is there for happens while the socket is coming up; once it is up, #ready is the engine’s to answer whenever it is ready to, and a drop from that point on arrives as an ordinary Disconnect. A watchdog that kept counting into the #ready wait would fail sessions that were about to succeed.

SocketOptions.WebsocketOptions is non-null out of the box with PingIntervalOverride set to TimeSpan.Zero, which WebSocketTransport reads as an explicit "no pings" and turns SendPings off. The only liveness check left is then Socket.IO’s own server-ping timer — PingInterval + PingTimeout, which the engine hands out as 25 s + 60 s, so 85 s. That is nearly three times the 30 s the engine then waits before abandoning the session, which is why a silent drop was unrecoverable no matter how well the client behaved.

That is fine on Android, where disabling Wi-Fi tears the socket down and surfaces a real TCP error at once, and useless on iOS, where the socket simply goes quiet. Detection there lands outside the engine’s 30 s window, so by the time the app starts reconnecting there is nothing left to reconnect to.

Turning websocket pings back on is the obvious fix and it does not work against this engine: with PingIntervalOverride at 3 s the connection was closed on a roughly ten-second cycle on both platforms, which is OverHTTP1’s ping-then-`CloseAfterNoMessage watchdog firing on a pong that never comes. Whether the engine ignores ping frames or closes on them was not established, only that the pong does not come back, and no value of CloseAfterNoMessage helps — one that does not false-positive would have to be longer than the server ping interval it is trying to beat. The setting is therefore left at the library’s default.

Nothing else inside the socket is a way around it: the engine.io ping is consumed by the transport before any namespace sees it, lastPingReceived is private to SocketManager, and during an idle conversation no elements arrive to time out on. Asking the OS instead is what the reachability poll above does, and it is the only thing that makes the common case — Wi-Fi switched off — detectable at all.

What the poll cannot see is a path that dies while still looking like the same path: an upstream break, a NAT table expiring, a captive portal starting to black-hole. Those still cost the full 85 s. Closing that gap needs the engine’s side: a lower pingTimeout, or a pingInterval short enough that the timer is not the long pole. TCP keepalive is the one remaining client-side lever — HTTPManager.PerHostSettings exposes it and Best.HTTP leaves it off by default, and unlike websocket ping frames the probes are answered by the peer’s kernel rather than the engine — but it only fires on an idle socket, and a conversation streaming microphone PCM is never idle, so it would cover the quiet moments only.

Those two values are the engine’s, sent in the engine.io handshake and adopted verbatim — protocol v4 has the server ping and the client pong, and no client-side override exists in the library. CreateSessionAsync logs them next to the ready line, so the figure above is whatever the deployment actually served rather than a default anyone assumed; the 60 s timeout in particular is three times the Socket.IO default, so somebody raised it deliberately. The Kotlin promethist-client SDKs sit behind the same timer on all four of their platforms and have no override either, so this is the engine’s number for every client, not a Unity problem.

That also makes the 30 s window narrower than it looks. It only starts once the drop is detected, so on a silent drop the engine must hold the session for the detection latency plus the client’s 30 s, not 30 s from the socket closing. If markAbandonedSessions is measuring from the close, a silent drop is unreconnectable by construction however well the client behaves.