feat!: Report a server-initiated stream close to the error handler

[jsonbailey]

Summary

When the server ends the stream and close was not called, the client now passes an SSE::Errors::StreamClosedByServerError to on_error. The client then reconnects as before.

This follows the WHATWG SSE processing model. On a normal end of body, the client must "reestablish the connection", and that step fires the error event. The Go, Java and Python eventsource libraries already report a server close to the error handler. Before this change, the Ruby gem reconnected silently.

Why now

The Ruby server SDK's RETRY conformance work (SDK-2793) controls the reconnect delay and waits in its error handler. It needs this signal. Without it, a server close reconnects with no delay.

Breaking change

A caller that calls close on any error now stops reconnecting after a server close. Release as 3.0.0.

Testing

• bundle exec rspec spec: 171 examples, 0 failures.
• bundle exec rubocop --parallel: 16 files inspected, no offenses.
• Ruby server SDK (SDK-2793 branch) full contract suite against 03c7b1a, with long-running tests enabled: 4697 tests ran, 0 failed.

Jira

SDK-3204

---

Note

Overview
Breaking: When the server ends the SSE body (EOF or nil from readpartial), the client now raises SSE::Errors::StreamClosedByServerError and delivers it to on_error before reconnecting, instead of exiting the read loop silently. Aligns with WHATWG SSE and other LaunchDarkly eventsource clients so callers can apply reconnect delay in the error handler.

ReadTimeoutError is unchanged and is not conflated with server close. Client-initiated close still avoids surfacing an error to on_error.

New specs cover EOF/nil paths, timeout vs close, no error on client close, and reconnect when the error handler raises. headers_spec uses the shared send_stream_content helper.

^{Reviewed by Cursor Bugbot for commit 03536d4. Bugbot is set up for automated code reviews on this repo. Configure here.}