A console reconnects to your Server-Sent Events feed with a `Last-Event-ID` older than anything the server still holds — what should it do?

## The specification hands you a value and stops A client that re-opens a dropped stream sends `Last-Event-ID` and nothing more. There is no field for "how far back can you go", no error the client understands as "too old", and no way for it to ask again with a different value. Whatever your handler writes next **is** the resumption, correct or not. So the first thing to be clear about is that this is an emitter design decision with no protocol default. ## Four things a handler can do, and what each costs | response to an unresumable id | what the client ends up with | cost to you | |---|---|---| | stream live events only | a silent gap it cannot detect | none, and that is why it happens | | replay the oldest events still held | wrong events presented as the missing ones | a lookup plus misleading data | | named gap event, then a snapshot, then live | correct current state and knowledge that it missed some | one snapshot per affected reconnect | | end the response and refuse | a client that re-opens on its delay with the same stale id and loops | a reconnect storm of your own making | Only the third is defensible for a warning surface. The first is the default behaviour of a handler that forgot to branch; the second is the failure mode of a replay store that clamps an out-of-range cursor to its oldest entry instead of reporting that it is out of range; the fourth trades a data problem for an availability problem, because a client that cannot progress will keep coming back with the same value. ## Why "gap event plus snapshot" is the shape to reach for A snapshot is **bounded**. Replay is proportional to how long the client was away; a snapshot of current level and current threshold state for every gauge in the catchment is the same size whether the outage lasted ninety seconds or a fortnight. That matters precisely when the window has been exceeded, which is to say when replay would have been largest. The named event matters just as much: 1. It lets the receiving application distinguish "you are caught up" from "you are current but missed some", which are different facts on an operational console. 2. It gives you somewhere to put the boundary — the oldest id you can still serve — so an operator debugging a hole in a trace can see where it starts. 3. It is observable at the emitter: counting how often you emit it tells you how often your window is actually too short, which is the only honest input to lengthening it. ## What the window really is, and what it costs The replay window is not a setting; it is a consequence. It is exactly as long as you keep the events that your ids address, in a form you can enumerate forward from a given id. Three costs follow: - **Retention.** Every extra hour of promised resumability is an hour of events kept somewhere addressable. - **Lookup.** Every reconnect that carries an id does a seek, and reconnects arrive in bursts — a link that drops for a whole district drops for every console in it at once. - **Write-path coupling.** Ids must be assigned where the events are durable, or the window you advertise is longer than the data you can actually produce. Publish the number, and publish the smaller of "what we retain" and "what we are willing to serve". A window you advertise but cannot honour under load is worse than a short one, because consumers will have written their catch-up logic against it. ## A first request carries no header at all Worth folding into the same branch: a client whose remembered id is empty sends no `Last-Event-ID` field. That is the same code path as an out-of-window resume — send current state, then live events — and treating both identically keeps one tested path instead of two. The difference is only in what you record: a missing header is a new subscriber, an unresumable id is a window miss, and conflating them in your metrics hides the signal that the window is too short.