The W3C SSE spec is mostly about edge cases: continuation data: lines accumulate with newlines, a leading space after the colon is consumed, lines starting with : are comments (Cloudflare uses these as keepalives), and retry: is a hint to the client about reconnect delay. Writing the parser as an async generator lets the caller iterate events without buffering the whole stream, which matters when you are tailing a 24-hour incident feed. The buffered id survives across event boundaries because the spec says id is sticky until the next id: line. I have re-implemented this enough times to know that keeping the field-parse logic in one place is worth the 30 lines.

The two pieces that turn this from a parser into a real client are the Last-Event-ID header on reconnect and bounded backoff. The header is the entire reason SSE is preferable to bare WebSockets for resumable feeds: a server that buffers events by id can replay everything the client missed without you writing your own checkpoint protocol. I treat the server's retry: hint as a baseline and multiply it by the attempt count, capped at maxBackoffMs, so a flapping server does not pin us in a tight loop. The AbortSignal lets a caller cancel cleanly, which is the difference between a useful library and one your QA team curses every time they kill a worker.