How do you handle an Anthropic SSE error event that arrives mid-stream?

## Why this question is asked at senior level Non-streamed failures are easy: you get a 4xx or 5xx, you branch on it. Streaming inverts that. The status line and headers are flushed when the first byte leaves, which means the request has already "succeeded" from HTTP's point of view before the model has generated anything. Every failure after that point has to be carried *inside* the stream. Candidates who have only built demos have never hit this; candidates who have shipped a chat UI have, and it shows. ## The two failure shapes **An `error` event.** The stream carries a frame whose payload is an error object with a `type` and a `message`. `overloaded_error` (capacity pressure) and `api_error` are the ones you will see mid-stream; request-shaped problems such as `invalid_request_error` and `authentication_error` normally fail before the stream opens. In the SDKs this is surfaced as an exception thrown from the iterator or streaming context manager, so your `for event in stream` loop needs a `try` around it, not just around the call that opened it. **A dead connection.** The socket closes, or goes silent forever, with no `error` event and no `message_stop`. Because you may already hold plausible-looking text, the only reliable detector is the terminator: if you never saw `message_stop`, the message is incomplete regardless of how good the prefix looks. Bake that assertion into the accumulator rather than leaving it to the caller. ## What you do about it **Decide the fate of the partial output explicitly.** There are only three honest choices, and the right one is product-dependent: discard it and show a failure; keep it on screen but mark it visibly as interrupted; or keep it and offer a continue action. What you must not do is leave partial text on screen styled exactly like a completed answer — that is how users end up quoting a sentence the model never finished. **Retry the whole request, with eyes open.** There is no cursor, offset or resume token; a retry is a fresh request that regenerates from the beginning and re-bills the input tokens (prompt caching reduces the cost of that re-send, not the fact of it). Use exponential backoff with jitter, cap the attempts, and only retry error types that are actually transient. If regeneration is expensive and you have a long partial answer, an alternative is to start a new request whose last message is an assistant turn containing the text you already have, so the model continues rather than restarts — a product decision with its own risks (the seam can be awkward, and it changes the prompt), not a protocol feature. **Make your own protocol able to say "failed".** If your backend relays to a browser, do not forward Anthropic's frames verbatim and do not signal failure by hanging up. Emit your own typed error frame, so the client can distinguish an interrupted generation from a completed one and can decide whether to offer retry. This is also where you strip provider details you do not want to leak and attach your own request id for support. **Observe it.** Count mid-stream failures separately from pre-stream failures. They have different causes and very different user impact: a pre-stream 529 is invisible behind a retry; a mid-stream failure at token 800 is visible, wasteful and, if you auto-retry, may show the user a second, differently-worded answer replacing the first. ## The idempotency angle Because a retry regenerates, any side effect you performed from partial output — a tool you already invoked, a row you already wrote, a message you already sent — can happen twice. The discipline is the same as anywhere else in distributed systems: do not act on a content block before its `content_block_stop`, and make downstream effects idempotent, keyed on something stable rather than on the stream itself.