A stream started with HTTP 200, then an error event of type overloaded_error arrived partway through. What does your client need?
Why C is the answer
Handling for error events inside the stream
Once a stream has started, the status code is already sent, so a later failure arrives as an event in the stream. Clients must handle it there and also tolerate event types they do not recognize.
In detail
- The HTTP status is sent when the stream starts.
- A later failure can only arrive as an event inside the stream.
- Clients should handle those events and tolerate types they do not recognize.
- Mark a reply incomplete unless message_stop arrived.
Use case
An illustrative scenario, not a real incident.
A client treats a 200 as success, so a stream that fails halfway shows as a short answer. Handling error events shows a retry option instead.
See it in different ways
sequenceDiagram participant A as API participant C as Your client A-->>C: message_start A-->>C: content_block_start A-->>C: content_block_delta, many times A-->>C: content_block_stop A-->>C: message_delta A-->>C: message_stop
sequenceDiagram participant P0 as Client participant P1 as API P0->>P1: Streaming request P1-->>P0: HTTP 200 and first events P1-->>P0: error event, overloaded_error P0->>P0: Show retry option
Key point: After a stream starts, errors arrive as events.
Why the other options are wrong
- A. A check that only the HTTP status code is 200
- The status code cannot report what happens after it has been sent.
- B. A longer socket timeout on the connection
- A timeout does not read an error event.
- D. Nothing, because a 200 status means the request succeeded
- The 200 only says the stream started, not that it finished.