A customer support platform streams Claude responses to end users via SSE (Server-Sent Events). The platform proxies Claude's streaming API through its own backend. Engineers report that when Claude's API returns a 500 error mid-stream — after tokens have already been sent to the customer — the platform's error handling code attempts to send an HTTP 500 status, which fails because the HTTP response was already committed with a 200 header. What is the correct architectural pattern for handling mid-stream errors?
Select an answer to reveal the explanation.
Short Explanation
Here's the deal — once the HTTP 200 streaming response is committed, you can't change the status code. You have to send mid-stream errors in-band as an SSE error event, so the client can handle them without a new HTTP status.
Full Explanation
Once an HTTP 200 response with streaming headers is committed, the HTTP status code cannot be changed. Mid-stream errors must be communicated in-band via the event stream itself. The standard pattern is to detect mid-stream errors and send a special error sentinel token in the SSE stream body, such as an SSE error event type — e.g., event: error and data: {"code": 500, "message": "..."} — that the client handles gracefully. This allows the client to display a partial response with an error notice, retry the request, or show a graceful fallback. Buffering the entire Claude response before sending eliminates the streaming UX benefit — users see a blank screen until the full response completes, which defeats the purpose of streaming. Closing the SSE connection immediately on any error relies on EventSource auto-reconnect, but Claude's stateless API won't resume generation mid-stream — it would restart from the beginning. Switching from streaming to polling solves the delivery problem but eliminates streaming latency benefits.