Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal for Handling Mid-Stream Errors in Server-Sent Events (SSE) #38

Open
brisacoder opened this issue Mar 6, 2025 · 0 comments
Open

Comments

@brisacoder
Copy link

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:

  • 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:

  1. 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).

  2. 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: error
data: {
  "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.

References

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant