View Source Stream replay-safety guide
An HTTP status code does not prove that a streamed operation completed. A connection can close after output was rendered, after a provider emitted an error event, or before a terminal marker. Replaying blindly can duplicate visible output or incur a second charge.
OpenaiSseGuard records bounded evidence without retaining the response body:
| Evidence | Snapshot effect | Application question |
|---|---|---|
[DONE] | termination: :done | Can the caller mark the stream complete? |
response.completed | termination: :done | Was a Responses terminal event observed? |
response.incomplete | termination: :incomplete | Does the provider require a follow-up? |
error event | termination: :error | Should the caller surface a provider error? |
| Named/data event then EOF | has_output: true, :unexpected_eof | Is replay unsafe without idempotency? |
| No event then EOF | :unexpected_eof | Is there enough evidence to retry? |
| Frame or event bound exceeded | :error | Should the transport be treated as untrusted? |
The package deliberately does not answer the final retry question. A caller should combine the snapshot with method semantics, an idempotency key, whether bytes were rendered, provider billing rules, cancellation state, and remaining budgets. A conservative false positive prevents a replay; a false negative can duplicate output or billing.
For wire framing, consult the WHATWG SSE specification. For provider errors, see the OpenAI error-code guide. For retry hints, see MDN Retry-After.