You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The existing AP specification defines several stream modes and standard HTTP error handling at connection initiation but lacks explicit guidance or a standardized schema for handling mid-stream errors—errors occurring after one or more SSE events have already been sent. Such errors may arise due to:
External data source failures
Authentication and authorization checks during streaming
Network or infrastructure failures during data retrieval
Recommended Approach
Best practices in the SSE community generally advise the following two-step error handling mechanism:
Before Sending SSE Events:
If an error is detected prior to sending any events, the server should respond immediately with the appropriate HTTP error status code (e.g., 4xx for client errors or 5xx for server errors).
After SSE Events Have Been Sent:
If an error occurs mid-stream (i.e., after at least one event has been sent), the server should:
Send a structured SSE error event.
Close the SSE connection immediately afterward to signal that the stream cannot continue.
Recommended Schema for SSE Error Events
To standardize error reporting and allow consistent client-side error handling, it's beneficial to adopt a structured error event schema. A practical example is:
event: errordata: {"type": "authentication_error",
"message": "Authentication failed during streaming due to expired token.",
"code": 401,
"timestamp": "2025-03-06T12:34:56Z"}
A real-world schema implementation can be referenced here:
This implementation clearly delineates error type, descriptive message, HTTP-like status code, and timestamp—enabling structured and actionable error handling on the client side.
Current Situation
The existing AP specification defines several stream modes and standard HTTP error handling at connection initiation but lacks explicit guidance or a standardized schema for handling mid-stream errors—errors occurring after one or more SSE events have already been sent. Such errors may arise due to:
Recommended Approach
Best practices in the SSE community generally advise the following two-step error handling mechanism:
Before Sending SSE Events:
If an error is detected prior to sending any events, the server should respond immediately with the appropriate HTTP error status code (e.g.,
4xx
for client errors or5xx
for server errors).After SSE Events Have Been Sent:
If an error occurs mid-stream (i.e., after at least one event has been sent), the server should:
Recommended Schema for SSE Error Events
To standardize error reporting and allow consistent client-side error handling, it's beneficial to adopt a structured error event schema. A practical example is:
A real-world schema implementation can be referenced here:
This implementation clearly delineates error type, descriptive message, HTTP-like status code, and timestamp—enabling structured and actionable error handling on the client side.
References
MDN Server-Sent Events
https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events
HTML Standard for Server-Sent Events (W3C Living Standard)
[https://html.spec.whatwg.org/multipage/server-sent-events.html](https://html.spec.whatwg.org/multipage/server-sent-events.html#server-sent-events)
Community discussions on mid-stream error handling:
The text was updated successfully, but these errors were encountered: