SSE Automatic Reconnection

Server-Sent Events (SSE) clients can automatically reconnect when an established connection is interrupted. A server can influence the reconnect delay by sending a `retry` field in an SSE event stream.

SSE uses the browser's `EventSource` API to maintain a long-lived HTTP connection to a server. If that connection ends unexpectedly, the client may attempt to establish a new connection automatically rather than requiring application code to create another connection.

The reconnect delay is controlled by the client's current retry setting. An SSE stream can send a `retry: <milliseconds>` field, which updates the delay used for subsequent reconnection attempts. The setting remains associated with that `EventSource` connection while it continues operating.

When reconnecting, the client can send a `Last-Event-ID` HTTP request header when it has received events with IDs. This allows a server to determine where the client last progressed and potentially replay missed events. The server-side application must support this mechanism if reliable event recovery is required.

Automatic reconnection is different from guaranteeing delivery. A connection can fail after the server has sent data but before the client has processed it, and reconnect behavior alone does not provide application-level exactly-once processing. Applications that require reliable state recovery should combine event IDs with suitable server-side replay or state synchronization.

Key points

• `EventSource` can automatically reconnect after an interrupted SSE connection.
• The SSE `retry` field specifies a reconnection delay in milliseconds.
• Event IDs enable clients to identify their last received event during reconnection.
• `Last-Event-ID` can let the server resume or replay events after a disconnect.
• Automatic reconnection does not by itself guarantee exactly-once delivery.

Interview questions

What happens when an SSE connection drops?

An `EventSource` client can automatically try to establish the connection again after an interruption. The reconnect timing is governed by the client's current retry delay. If the server has supplied a `retry` field, that value can change the delay used for later attempts. This means basic reconnection does not require the application to manually create a new `EventSource` after every disconnect.

What does the SSE `retry` field do?

The `retry` field specifies the reconnection delay in milliseconds for the SSE client. For example, `retry: 5000` tells an EventSource client to use a five-second delay for subsequent reconnect attempts. It is part of the SSE stream format rather than an HTTP response header. The value should therefore be emitted as SSE-formatted data.

Why are SSE event IDs useful during reconnection?

An SSE event can include an `id` field that identifies its position in the stream. After receiving such events, a reconnecting client can communicate its last event ID using `Last-Event-ID`. The server can use that information to replay events that the client may have missed. This requires server-side support for retaining or reconstructing the relevant events.

Does SSE automatic reconnection guarantee exactly-once message delivery?

No. Reconnection only addresses restoring the connection; it does not establish exactly-once processing semantics. A client can reconnect after an uncertain failure point and receive an event again, or it can miss events if the server has no replay mechanism. Applications needing stronger guarantees typically use event IDs, durable replay, idempotent processing, or explicit state synchronization.