An architect is designing the Messages API integration for a streaming chatbot. The frontend displays tokens as they are generated. After receiving a message_start event, the client receives repeated content_block_delta events, then unexpectedly receives an error event mid-stream. What is the correct handling strategy?
Select an answer to reveal the explanation.
Short Explanation
When an SSE stream throws an error mid-generation, close the connection, show the partial tokens you already got, flag it as incomplete, and let the user retry. Don't throw away valid output or hide the failure behind silent retries.
Full Explanation
When an SSE stream is interrupted by an error event, the correct UX and architectural response is to close the connection cleanly, preserve and display the partial content already received because it was valid output, mark it as incomplete with a visual indicator, and present a retry option to the user. An approach that discards all received tokens and retries the entire request from the beginning with exponential backoff degrades UX and wastes compute for long generations, especially when it happens without user awareness. Treating all streamed tokens received before the error as complete and using the error's token count to re-request only the missing portion is incorrect because the Anthropic API does not provide a partial-retry offset; if retrying, you must restart the full request from the beginning. Buffering all streamed content and displaying it only after message_stop, then silently retrying the full request on error, defeats the purpose of streaming and creates bad UX; errors should surface immediately so the user isn't left waiting on a failed connection. The correct strategy prioritizes user transparency and graceful degradation.