Your page's EventSource keeps firing its `error` event and the Network panel shows the request being re-issued, yet nothing in your code reopened the stream. What is EventSource doing, and when does it stop retrying on its own?

## Reconnection is the feature The reason to reach for `EventSource` at all, rather than reading a long-lived response yourself, is that the browser runs the reconnect loop for you. When the connection breaks — a laptop lid closes, a load balancer recycles a backend, a mobile network hands off — the browser fires an `error` event, puts `readyState` back to `CONNECTING`, waits a short interval, and issues the request again. Your application code contains no retry logic and no backoff timer. That convenience is exactly what surprises people the first time. Seeing repeated `error` events plus repeated requests in the Network panel looks like a bug in your code. It is not; it is the API working. ## error is a status update, not a verdict Because `error` covers both "dropped, retrying" and "finished, not retrying", the event alone tells you nothing. The state does: ```js es.addEventListener('error', () => { switch (es.readyState) { case EventSource.CONNECTING: // 0 — a retry is already scheduled showBanner('Reconnecting…'); break; case EventSource.CLOSED: // 2 — the browser has given up showBanner('Live updates unavailable'); break; } }); ``` The three states are `EventSource.CONNECTING` (0), `EventSource.OPEN` (1) and `EventSource.CLOSED` (2), and they are exposed as constants on the constructor so you never hard-code the numbers. A UI that flashes a red "connection lost" banner on every `error` will flicker constantly on a mobile network; gate it on the state, and ideally on the state persisting for a few seconds. ## The two ways it stops for good First, **you called `es.close()`**. `readyState` becomes `CLOSED` immediately and no further requests are made. This is the only clean shutdown, and there is no reopen — you construct a new `EventSource` if you want the feed back. Second, **the browser rejected the response**. If the response arrives with a status other than 200, or with a `Content-Type` that is not `text/event-stream`, the browser fails the connection: it fires `error`, sets `readyState` to `CLOSED`, and does not retry. That second rule has a sharp production consequence. A session that expires mid-stream typically means the next reconnect gets a 401 or a redirect to an HTML login page — neither is a 200 `text/event-stream`, so the stream dies permanently and silently while the rest of the app keeps working. Any real integration needs an `error` handler that notices `CLOSED` and either re-authenticates and builds a fresh `EventSource`, or tells the user the feed is stale. "It worked in dev because my session never expired" is the classic version of this bug. ## You do not control the retry delay from the client The reconnection interval is not a constructor option and there is no client-side API to change it. It is a property of the stream, chosen by the server side, with a browser default when the server says nothing. From the client's point of view, this means two things: you cannot implement client-side exponential backoff inside `EventSource`, and if you need a specific backoff policy you either negotiate it with the server or stop using `EventSource` and read the stream yourself. If the stream is permanently `CLOSED` and you rebuild it in a loop, **you** are now the retry loop, and you must add the backoff the browser would otherwise have provided. Rebuilding immediately on every failure turns one broken deploy into a self-inflicted request flood from every open tab. ## Design for gaps and duplicates Every reconnect is a brand-new HTTP request, and the browser automatically tells the server where the client left off using the last message id it saw. Whether the server can actually resume from that point is a server design question — many cannot, and simply start sending from now. So the client must be written for two realities. **Gaps**: messages produced while disconnected may never arrive, which is why a feed of *deltas* is fragile and a feed of *current state* (or a delta feed plus a "refetch the snapshot on reconnect" step) is robust. **Duplicates**: a resumed stream may re-send messages you already applied, so handlers should be idempotent — keyed upserts rather than `count += 1`. Both problems are invisible in development, where the connection never breaks, and both surface on the first real mobile user. A good habit is to treat `open` as a resync point: on every `open` after the first, refetch the authoritative snapshot once, then let the stream carry you forward. That single line of policy removes an entire class of drift bugs.