A streaming answer disconnects midway: how do you distinguish completion, failure and truncation?
For interrupted streams, inspect final business events and stop reasons rather than equate connection closure with completion. Network chunks need not contain complete SSE events, and errors may arrive after an initial success status.
Start troubleshooting here
For interrupted streams, inspect final business events and stop reasons rather than equate connection closure with completion. Network chunks need not contain complete SSE events, and errors may arrive after an initial success status. Parse the protocol and retain normal, canceled and abnormal termination separately. Partial text must not automatically publish as a complete answer.
Preserve the final event and business termination state
This applies to half-sentences without visible errors and incomplete tool arguments. Preserve safe event types, times and request IDs and establish whether completion was sent. An established HTTP connection only begins transport. Proxy closure, timeouts and output-length truncation can occur later and require more than initial-status inspection.
Separate closed transport from protocol completion
Check SSE buffering instead of interpreting each network chunk as a whole message. Inspect errors, completion and stop reasons alongside proxy and heartbeat behavior. Handle unknown events according to service guidance without discarding business errors. Automatic reconnection does not guarantee duplicate-free continuation of model generation.
Handle content, errors and cancellation by event type
Separate event parsing, content accumulation and completion state, marking complete only after protocol-confirmed termination and usable output. Preserve partial text and explanations on interruption and offer supported retry or recovery. Wait for complete, validated tool arguments before actions, especially writes. Cancellation should also stop local processing and queued retries.
Test normal completion, interruption and truncation separately
Test complete, disconnected and service-truncated responses with controlled samples and verify consistent UI and backend states. Partial text must not become a complete answer, error events must remain visible and recovery must not repeat actions. Success requires an explainable state for every termination type, not merely received text or an inactive connection.
This article interrupted no real model call or paid test and assumes no universal completion-event name. SSE defines event transport, while business completion follows the service protocol. Partial responses may be useful when labeled. If resumption is unsupported, do not invent it or silently append a fresh random answer to an old fragment.
Checked sources
These sources support the concepts and methods described here. Examples and test scope are labeled separately; check the version of the tools you use.