feat: add resilient SSE session with reconnection/backoff by dogo · Pull Request #43 · Recouse/EventSource

dogo · 2025-10-01T11:11:00Z

• Implement exponential backoff reconnection with configurable limits (maxReconnectAttempts, reconnectInitialDelay, reconnectBackoffFactor)
• Track reconnect attempts and readyState using thread-safe Mutex; reset attempts on successful .open

• Implement exponential backoff reconnection with configurable limits (maxReconnectAttempts, reconnectInitialDelay, reconnectBackoffFactor) • Track reconnect attempts and readyState using thread-safe Mutex; reset attempts on successful .open

dogo · 2025-11-12T15:21:01Z

Hey @Recouse, I’ve resolved the conflicts and the CI has passed. Could you please review the code when you have a moment?

dogo · 2026-02-20T22:20:26Z

Hi @Recouse 👋

Before moving forward with this PR, I just wanted to check if there’s still interest in the feature it introduces. If not, no worries at all, I’m happy to close it. Just let me know 🙂

…connect

Recouse · 2026-02-21T09:19:23Z

Hi,
Yes, I’m interested in this feature. It had reconnection support in earlier versions, but I removed it because the implementation was unstable.

Recouse

Have you tested the implementation? At first glance, it looks fine, but there may be some caveats with SessionDelegate and URLSession instances from the initial request.

Recouse · 2026-02-21T09:23:01Z

+ /// Helper method for reconnection
+ private func attemptReconnect(stream continuation: AsyncStream<EventType>.Continuation) {
+ let delay = reconnectInitialDelay * pow(reconnectBackoffFactor, Double(reconnectAttempts - 1))
+ DispatchQueue.global().asyncAfter(deadline: .now() + delay) { [weak self] in


Would it possible to implement this with Task.sleep()?

Recouse · 2026-02-21T11:21:48Z

 /// it can be started by iterating event stream returned by ``DataTask/events()``.
 final class DataTask: Sendable {
+ /// Initializes or reinitializes the SSE session
+ private func startSession(stream continuation: AsyncStream<EventType>.Continuation) {


It's more of a stylistic request to declare methods after init()

dogo · 2026-02-23T11:54:08Z

Hi, Yes, I’m interested in this feature. It had reconnection support in earlier versions, but I removed it because the implementation was unstable.

Yes, I’ve tested the reconnection flow with:

normal connection
forced network drop
server-side close
manual cancellation

The session is properly invalidated before creating a new one, and the delegate is not reused across sessions to avoid unexpected behavior.

Recouse

In my tests I've noticed that the current logic relies on the URLSession:task:didCompleteWithError: delegate method to complete the request. I've added an error != nil check to properly close the connection when reconnection is not needed.

There's another issue: reconnection happens indefinitely, because on reconnection readyState becomes .connecting, and after the first response it's set to .open and resets reconnectAttempts. As a result, the request never finishes and re-runs indefinitely.

Recouse · 2026-02-24T21:23:23Z

+ // Attempts to reconnect if the limit has not been exceeded
+ if reconnectAttempts < maxReconnectAttempts {


Suggested change
// Attempts to reconnect if the limit has not been exceeded
if reconnectAttempts < maxReconnectAttempts {
// If an error occurred, an error object will indicate how the request failed, otherwise nil.
// Attempts to reconnect on error if the limit has not been exceeded.
if error !=nil, reconnectAttempts < maxReconnectAttempts {

Recouse · 2026-02-24T21:53:13Z

Turns out it requires an overhaul of the DataTask implementation. I also wanted to reduce the Mutex count, and either switch to a single state value or make DataTask an actor. I think it will be better to put this PR on hold and return to it later.

dogo · 2026-02-25T10:51:58Z

Turns out it requires an overhaul of the DataTask implementation. I also wanted to reduce the Mutex count, and either switch to a single state value or make DataTask an actor. I think it will be better to put this PR on hold and return to it later.

That makes sense. I agree the current approach introduces complexity in state management and reconnection flow.

Switching DataTask to an actor sounds like a much cleaner solution and would eliminate the need for multiple mutexes.

I'm happy to put this PR on hold and revisit it with a redesigned implementation.

dogo · 2025-10-01T11:11:00Z

• Implement exponential backoff reconnection with configurable limits (maxReconnectAttempts, reconnectInitialDelay, reconnectBackoffFactor)
• Track reconnect attempts and readyState using thread-safe Mutex; reset attempts on successful .open

• Implement exponential backoff reconnection with configurable limits (maxReconnectAttempts, reconnectInitialDelay, reconnectBackoffFactor) • Track reconnect attempts and readyState using thread-safe Mutex; reset attempts on successful .open

dogo · 2025-11-12T15:21:01Z

Hey @Recouse, I’ve resolved the conflicts and the CI has passed. Could you please review the code when you have a moment?

dogo · 2026-02-20T22:20:26Z

Hi @Recouse 👋

Before moving forward with this PR, I just wanted to check if there’s still interest in the feature it introduces. If not, no worries at all, I’m happy to close it. Just let me know 🙂

…connect

Recouse · 2026-02-21T09:19:23Z

Hi,
Yes, I’m interested in this feature. It had reconnection support in earlier versions, but I removed it because the implementation was unstable.

Recouse

Have you tested the implementation? At first glance, it looks fine, but there may be some caveats with SessionDelegate and URLSession instances from the initial request.

Recouse · 2026-02-21T09:23:01Z

+ /// Helper method for reconnection
+ private func attemptReconnect(stream continuation: AsyncStream<EventType>.Continuation) {
+ let delay = reconnectInitialDelay * pow(reconnectBackoffFactor, Double(reconnectAttempts - 1))
+ DispatchQueue.global().asyncAfter(deadline: .now() + delay) { [weak self] in


Would it possible to implement this with Task.sleep()?

Recouse · 2026-02-21T11:21:48Z

 /// it can be started by iterating event stream returned by ``DataTask/events()``.
 final class DataTask: Sendable {
+ /// Initializes or reinitializes the SSE session
+ private func startSession(stream continuation: AsyncStream<EventType>.Continuation) {


It's more of a stylistic request to declare methods after init()

dogo · 2026-02-23T11:54:08Z

Hi, Yes, I’m interested in this feature. It had reconnection support in earlier versions, but I removed it because the implementation was unstable.

Yes, I’ve tested the reconnection flow with:

normal connection
forced network drop
server-side close
manual cancellation

The session is properly invalidated before creating a new one, and the delegate is not reused across sessions to avoid unexpected behavior.

Recouse

In my tests I've noticed that the current logic relies on the URLSession:task:didCompleteWithError: delegate method to complete the request. I've added an error != nil check to properly close the connection when reconnection is not needed.

There's another issue: reconnection happens indefinitely, because on reconnection readyState becomes .connecting, and after the first response it's set to .open and resets reconnectAttempts. As a result, the request never finishes and re-runs indefinitely.

Recouse · 2026-02-24T21:23:23Z

+ // Attempts to reconnect if the limit has not been exceeded
+ if reconnectAttempts < maxReconnectAttempts {


Suggested change
// Attempts to reconnect if the limit has not been exceeded
if reconnectAttempts < maxReconnectAttempts {
// If an error occurred, an error object will indicate how the request failed, otherwise nil.
// Attempts to reconnect on error if the limit has not been exceeded.
if error !=nil, reconnectAttempts < maxReconnectAttempts {

Recouse · 2026-02-24T21:53:13Z

Turns out it requires an overhaul of the DataTask implementation. I also wanted to reduce the Mutex count, and either switch to a single state value or make DataTask an actor. I think it will be better to put this PR on hold and return to it later.

dogo · 2026-02-25T10:51:58Z

Turns out it requires an overhaul of the DataTask implementation. I also wanted to reduce the Mutex count, and either switch to a single state value or make DataTask an actor. I think it will be better to put this PR on hold and return to it later.

That makes sense. I agree the current approach introduces complexity in state management and reconnection flow.

Switching DataTask to an actor sounds like a much cleaner solution and would eliminate the need for multiple mutexes.

I'm happy to put this PR on hold and revisit it with a redesigned implementation.

dogo · 2025-10-01T11:11:00Z

• Implement exponential backoff reconnection with configurable limits (maxReconnectAttempts, reconnectInitialDelay, reconnectBackoffFactor)
• Track reconnect attempts and readyState using thread-safe Mutex; reset attempts on successful .open

• Implement exponential backoff reconnection with configurable limits (maxReconnectAttempts, reconnectInitialDelay, reconnectBackoffFactor) • Track reconnect attempts and readyState using thread-safe Mutex; reset attempts on successful .open

dogo · 2025-11-12T15:21:01Z

Hey @Recouse, I’ve resolved the conflicts and the CI has passed. Could you please review the code when you have a moment?

dogo · 2026-02-20T22:20:26Z

Hi @Recouse 👋

Before moving forward with this PR, I just wanted to check if there’s still interest in the feature it introduces. If not, no worries at all, I’m happy to close it. Just let me know 🙂

…connect

Recouse · 2026-02-21T09:19:23Z

Hi,
Yes, I’m interested in this feature. It had reconnection support in earlier versions, but I removed it because the implementation was unstable.

Recouse

Have you tested the implementation? At first glance, it looks fine, but there may be some caveats with SessionDelegate and URLSession instances from the initial request.

Recouse · 2026-02-21T09:23:01Z

+ /// Helper method for reconnection
+ private func attemptReconnect(stream continuation: AsyncStream<EventType>.Continuation) {
+ let delay = reconnectInitialDelay * pow(reconnectBackoffFactor, Double(reconnectAttempts - 1))
+ DispatchQueue.global().asyncAfter(deadline: .now() + delay) { [weak self] in


Would it possible to implement this with Task.sleep()?

Recouse · 2026-02-21T11:21:48Z

 /// it can be started by iterating event stream returned by ``DataTask/events()``.
 final class DataTask: Sendable {
+ /// Initializes or reinitializes the SSE session
+ private func startSession(stream continuation: AsyncStream<EventType>.Continuation) {


It's more of a stylistic request to declare methods after init()

dogo · 2026-02-23T11:54:08Z

Hi, Yes, I’m interested in this feature. It had reconnection support in earlier versions, but I removed it because the implementation was unstable.

Yes, I’ve tested the reconnection flow with:

normal connection
forced network drop
server-side close
manual cancellation

The session is properly invalidated before creating a new one, and the delegate is not reused across sessions to avoid unexpected behavior.

Recouse

In my tests I've noticed that the current logic relies on the URLSession:task:didCompleteWithError: delegate method to complete the request. I've added an error != nil check to properly close the connection when reconnection is not needed.

There's another issue: reconnection happens indefinitely, because on reconnection readyState becomes .connecting, and after the first response it's set to .open and resets reconnectAttempts. As a result, the request never finishes and re-runs indefinitely.

Recouse · 2026-02-24T21:23:23Z

+ // Attempts to reconnect if the limit has not been exceeded
+ if reconnectAttempts < maxReconnectAttempts {


Suggested change
// Attempts to reconnect if the limit has not been exceeded
if reconnectAttempts < maxReconnectAttempts {
// If an error occurred, an error object will indicate how the request failed, otherwise nil.
// Attempts to reconnect on error if the limit has not been exceeded.
if error !=nil, reconnectAttempts < maxReconnectAttempts {

Recouse · 2026-02-24T21:53:13Z

Turns out it requires an overhaul of the DataTask implementation. I also wanted to reduce the Mutex count, and either switch to a single state value or make DataTask an actor. I think it will be better to put this PR on hold and return to it later.

dogo · 2026-02-25T10:51:58Z

Turns out it requires an overhaul of the DataTask implementation. I also wanted to reduce the Mutex count, and either switch to a single state value or make DataTask an actor. I think it will be better to put this PR on hold and return to it later.

That makes sense. I agree the current approach introduces complexity in state management and reconnection flow.

Switching DataTask to an actor sounds like a much cleaner solution and would eliminate the need for multiple mutexes.

I'm happy to put this PR on hold and revisit it with a redesigned implementation.

dogo · 2025-10-01T11:11:00Z

• Implement exponential backoff reconnection with configurable limits (maxReconnectAttempts, reconnectInitialDelay, reconnectBackoffFactor)
• Track reconnect attempts and readyState using thread-safe Mutex; reset attempts on successful .open

• Implement exponential backoff reconnection with configurable limits (maxReconnectAttempts, reconnectInitialDelay, reconnectBackoffFactor) • Track reconnect attempts and readyState using thread-safe Mutex; reset attempts on successful .open

dogo · 2025-11-12T15:21:01Z

Hey @Recouse, I’ve resolved the conflicts and the CI has passed. Could you please review the code when you have a moment?

dogo · 2026-02-20T22:20:26Z

Hi @Recouse 👋

Before moving forward with this PR, I just wanted to check if there’s still interest in the feature it introduces. If not, no worries at all, I’m happy to close it. Just let me know 🙂

…connect

Recouse · 2026-02-21T09:19:23Z

Hi,
Yes, I’m interested in this feature. It had reconnection support in earlier versions, but I removed it because the implementation was unstable.

Recouse

Have you tested the implementation? At first glance, it looks fine, but there may be some caveats with SessionDelegate and URLSession instances from the initial request.

Recouse · 2026-02-21T09:23:01Z

+ /// Helper method for reconnection
+ private func attemptReconnect(stream continuation: AsyncStream<EventType>.Continuation) {
+ let delay = reconnectInitialDelay * pow(reconnectBackoffFactor, Double(reconnectAttempts - 1))
+ DispatchQueue.global().asyncAfter(deadline: .now() + delay) { [weak self] in


Would it possible to implement this with Task.sleep()?

Recouse · 2026-02-21T11:21:48Z

 /// it can be started by iterating event stream returned by ``DataTask/events()``.
 final class DataTask: Sendable {
+ /// Initializes or reinitializes the SSE session
+ private func startSession(stream continuation: AsyncStream<EventType>.Continuation) {


It's more of a stylistic request to declare methods after init()

dogo · 2026-02-23T11:54:08Z

Hi, Yes, I’m interested in this feature. It had reconnection support in earlier versions, but I removed it because the implementation was unstable.

Yes, I’ve tested the reconnection flow with:

normal connection
forced network drop
server-side close
manual cancellation

The session is properly invalidated before creating a new one, and the delegate is not reused across sessions to avoid unexpected behavior.

Recouse

In my tests I've noticed that the current logic relies on the URLSession:task:didCompleteWithError: delegate method to complete the request. I've added an error != nil check to properly close the connection when reconnection is not needed.

There's another issue: reconnection happens indefinitely, because on reconnection readyState becomes .connecting, and after the first response it's set to .open and resets reconnectAttempts. As a result, the request never finishes and re-runs indefinitely.

Recouse · 2026-02-24T21:23:23Z

+ // Attempts to reconnect if the limit has not been exceeded
+ if reconnectAttempts < maxReconnectAttempts {


Suggested change
// Attempts to reconnect if the limit has not been exceeded
if reconnectAttempts < maxReconnectAttempts {
// If an error occurred, an error object will indicate how the request failed, otherwise nil.
// Attempts to reconnect on error if the limit has not been exceeded.
if error !=nil, reconnectAttempts < maxReconnectAttempts {

Recouse · 2026-02-24T21:53:13Z

Turns out it requires an overhaul of the DataTask implementation. I also wanted to reduce the Mutex count, and either switch to a single state value or make DataTask an actor. I think it will be better to put this PR on hold and return to it later.

dogo · 2026-02-25T10:51:58Z

Turns out it requires an overhaul of the DataTask implementation. I also wanted to reduce the Mutex count, and either switch to a single state value or make DataTask an actor. I think it will be better to put this PR on hold and return to it later.

That makes sense. I agree the current approach introduces complexity in state management and reconnection flow.

Switching DataTask to an actor sounds like a much cleaner solution and would eliminate the need for multiple mutexes.

I'm happy to put this PR on hold and revisit it with a redesigned implementation.

dogo · 2025-10-01T11:11:00Z

• Implement exponential backoff reconnection with configurable limits (maxReconnectAttempts, reconnectInitialDelay, reconnectBackoffFactor)
• Track reconnect attempts and readyState using thread-safe Mutex; reset attempts on successful .open

• Implement exponential backoff reconnection with configurable limits (maxReconnectAttempts, reconnectInitialDelay, reconnectBackoffFactor) • Track reconnect attempts and readyState using thread-safe Mutex; reset attempts on successful .open

dogo · 2025-11-12T15:21:01Z

Hey @Recouse, I’ve resolved the conflicts and the CI has passed. Could you please review the code when you have a moment?

dogo · 2026-02-20T22:20:26Z

Hi @Recouse 👋

Before moving forward with this PR, I just wanted to check if there’s still interest in the feature it introduces. If not, no worries at all, I’m happy to close it. Just let me know 🙂

…connect

Recouse · 2026-02-21T09:19:23Z

Hi,
Yes, I’m interested in this feature. It had reconnection support in earlier versions, but I removed it because the implementation was unstable.

Recouse

Have you tested the implementation? At first glance, it looks fine, but there may be some caveats with SessionDelegate and URLSession instances from the initial request.

Recouse · 2026-02-21T09:23:01Z

+ /// Helper method for reconnection
+ private func attemptReconnect(stream continuation: AsyncStream<EventType>.Continuation) {
+ let delay = reconnectInitialDelay * pow(reconnectBackoffFactor, Double(reconnectAttempts - 1))
+ DispatchQueue.global().asyncAfter(deadline: .now() + delay) { [weak self] in


Would it possible to implement this with Task.sleep()?

Recouse · 2026-02-21T11:21:48Z

 /// it can be started by iterating event stream returned by ``DataTask/events()``.
 final class DataTask: Sendable {
+ /// Initializes or reinitializes the SSE session
+ private func startSession(stream continuation: AsyncStream<EventType>.Continuation) {


It's more of a stylistic request to declare methods after init()

dogo · 2026-02-23T11:54:08Z

Hi, Yes, I’m interested in this feature. It had reconnection support in earlier versions, but I removed it because the implementation was unstable.

Yes, I’ve tested the reconnection flow with:

normal connection
forced network drop
server-side close
manual cancellation

The session is properly invalidated before creating a new one, and the delegate is not reused across sessions to avoid unexpected behavior.

Recouse

In my tests I've noticed that the current logic relies on the URLSession:task:didCompleteWithError: delegate method to complete the request. I've added an error != nil check to properly close the connection when reconnection is not needed.

There's another issue: reconnection happens indefinitely, because on reconnection readyState becomes .connecting, and after the first response it's set to .open and resets reconnectAttempts. As a result, the request never finishes and re-runs indefinitely.

Recouse · 2026-02-24T21:23:23Z

+ // Attempts to reconnect if the limit has not been exceeded
+ if reconnectAttempts < maxReconnectAttempts {


Suggested change
// Attempts to reconnect if the limit has not been exceeded
if reconnectAttempts < maxReconnectAttempts {
// If an error occurred, an error object will indicate how the request failed, otherwise nil.
// Attempts to reconnect on error if the limit has not been exceeded.
if error !=nil, reconnectAttempts < maxReconnectAttempts {

Recouse · 2026-02-24T21:53:13Z

Turns out it requires an overhaul of the DataTask implementation. I also wanted to reduce the Mutex count, and either switch to a single state value or make DataTask an actor. I think it will be better to put this PR on hold and return to it later.

dogo · 2026-02-25T10:51:58Z

Turns out it requires an overhaul of the DataTask implementation. I also wanted to reduce the Mutex count, and either switch to a single state value or make DataTask an actor. I think it will be better to put this PR on hold and return to it later.

That makes sense. I agree the current approach introduces complexity in state management and reconnection flow.

Switching DataTask to an actor sounds like a much cleaner solution and would eliminate the need for multiple mutexes.

I'm happy to put this PR on hold and revisit it with a redesigned implementation.

dogo · 2025-10-01T11:11:00Z

• Implement exponential backoff reconnection with configurable limits (maxReconnectAttempts, reconnectInitialDelay, reconnectBackoffFactor)
• Track reconnect attempts and readyState using thread-safe Mutex; reset attempts on successful .open

• Implement exponential backoff reconnection with configurable limits (maxReconnectAttempts, reconnectInitialDelay, reconnectBackoffFactor) • Track reconnect attempts and readyState using thread-safe Mutex; reset attempts on successful .open

dogo · 2025-11-12T15:21:01Z

Hey @Recouse, I’ve resolved the conflicts and the CI has passed. Could you please review the code when you have a moment?

dogo · 2026-02-20T22:20:26Z

Hi @Recouse 👋

Before moving forward with this PR, I just wanted to check if there’s still interest in the feature it introduces. If not, no worries at all, I’m happy to close it. Just let me know 🙂

…connect

Recouse · 2026-02-21T09:19:23Z

Hi,
Yes, I’m interested in this feature. It had reconnection support in earlier versions, but I removed it because the implementation was unstable.

Recouse

Have you tested the implementation? At first glance, it looks fine, but there may be some caveats with SessionDelegate and URLSession instances from the initial request.

Recouse · 2026-02-21T09:23:01Z

+ /// Helper method for reconnection
+ private func attemptReconnect(stream continuation: AsyncStream<EventType>.Continuation) {
+ let delay = reconnectInitialDelay * pow(reconnectBackoffFactor, Double(reconnectAttempts - 1))
+ DispatchQueue.global().asyncAfter(deadline: .now() + delay) { [weak self] in


Would it possible to implement this with Task.sleep()?

Recouse · 2026-02-21T11:21:48Z

 /// it can be started by iterating event stream returned by ``DataTask/events()``.
 final class DataTask: Sendable {
+ /// Initializes or reinitializes the SSE session
+ private func startSession(stream continuation: AsyncStream<EventType>.Continuation) {


It's more of a stylistic request to declare methods after init()

dogo · 2026-02-23T11:54:08Z

Hi, Yes, I’m interested in this feature. It had reconnection support in earlier versions, but I removed it because the implementation was unstable.

Yes, I’ve tested the reconnection flow with:

normal connection
forced network drop
server-side close
manual cancellation

The session is properly invalidated before creating a new one, and the delegate is not reused across sessions to avoid unexpected behavior.

Recouse

In my tests I've noticed that the current logic relies on the URLSession:task:didCompleteWithError: delegate method to complete the request. I've added an error != nil check to properly close the connection when reconnection is not needed.

There's another issue: reconnection happens indefinitely, because on reconnection readyState becomes .connecting, and after the first response it's set to .open and resets reconnectAttempts. As a result, the request never finishes and re-runs indefinitely.

Recouse · 2026-02-24T21:23:23Z

+ // Attempts to reconnect if the limit has not been exceeded
+ if reconnectAttempts < maxReconnectAttempts {


Suggested change
// Attempts to reconnect if the limit has not been exceeded
if reconnectAttempts < maxReconnectAttempts {
// If an error occurred, an error object will indicate how the request failed, otherwise nil.
// Attempts to reconnect on error if the limit has not been exceeded.
if error !=nil, reconnectAttempts < maxReconnectAttempts {

Recouse · 2026-02-24T21:53:13Z

Turns out it requires an overhaul of the DataTask implementation. I also wanted to reduce the Mutex count, and either switch to a single state value or make DataTask an actor. I think it will be better to put this PR on hold and return to it later.

dogo · 2026-02-25T10:51:58Z

Turns out it requires an overhaul of the DataTask implementation. I also wanted to reduce the Mutex count, and either switch to a single state value or make DataTask an actor. I think it will be better to put this PR on hold and return to it later.

That makes sense. I agree the current approach introduces complexity in state management and reconnection flow.

Switching DataTask to an actor sounds like a much cleaner solution and would eliminate the need for multiple mutexes.

I'm happy to put this PR on hold and revisit it with a redesigned implementation.

dogo · 2025-10-01T11:11:00Z

• Implement exponential backoff reconnection with configurable limits (maxReconnectAttempts, reconnectInitialDelay, reconnectBackoffFactor)
• Track reconnect attempts and readyState using thread-safe Mutex; reset attempts on successful .open

• Implement exponential backoff reconnection with configurable limits (maxReconnectAttempts, reconnectInitialDelay, reconnectBackoffFactor) • Track reconnect attempts and readyState using thread-safe Mutex; reset attempts on successful .open

dogo · 2025-11-12T15:21:01Z

Hey @Recouse, I’ve resolved the conflicts and the CI has passed. Could you please review the code when you have a moment?

dogo · 2026-02-20T22:20:26Z

Hi @Recouse 👋

Before moving forward with this PR, I just wanted to check if there’s still interest in the feature it introduces. If not, no worries at all, I’m happy to close it. Just let me know 🙂

…connect

Recouse · 2026-02-21T09:19:23Z

Hi,
Yes, I’m interested in this feature. It had reconnection support in earlier versions, but I removed it because the implementation was unstable.

Recouse

Have you tested the implementation? At first glance, it looks fine, but there may be some caveats with SessionDelegate and URLSession instances from the initial request.

Recouse · 2026-02-21T09:23:01Z

+ /// Helper method for reconnection
+ private func attemptReconnect(stream continuation: AsyncStream<EventType>.Continuation) {
+ let delay = reconnectInitialDelay * pow(reconnectBackoffFactor, Double(reconnectAttempts - 1))
+ DispatchQueue.global().asyncAfter(deadline: .now() + delay) { [weak self] in


Would it possible to implement this with Task.sleep()?

Recouse · 2026-02-21T11:21:48Z

 /// it can be started by iterating event stream returned by ``DataTask/events()``.
 final class DataTask: Sendable {
+ /// Initializes or reinitializes the SSE session
+ private func startSession(stream continuation: AsyncStream<EventType>.Continuation) {


It's more of a stylistic request to declare methods after init()

dogo · 2026-02-23T11:54:08Z

Hi, Yes, I’m interested in this feature. It had reconnection support in earlier versions, but I removed it because the implementation was unstable.

Yes, I’ve tested the reconnection flow with:

normal connection
forced network drop
server-side close
manual cancellation

The session is properly invalidated before creating a new one, and the delegate is not reused across sessions to avoid unexpected behavior.

Recouse

In my tests I've noticed that the current logic relies on the URLSession:task:didCompleteWithError: delegate method to complete the request. I've added an error != nil check to properly close the connection when reconnection is not needed.

There's another issue: reconnection happens indefinitely, because on reconnection readyState becomes .connecting, and after the first response it's set to .open and resets reconnectAttempts. As a result, the request never finishes and re-runs indefinitely.

Recouse · 2026-02-24T21:23:23Z

+ // Attempts to reconnect if the limit has not been exceeded
+ if reconnectAttempts < maxReconnectAttempts {


Suggested change
// Attempts to reconnect if the limit has not been exceeded
if reconnectAttempts < maxReconnectAttempts {
// If an error occurred, an error object will indicate how the request failed, otherwise nil.
// Attempts to reconnect on error if the limit has not been exceeded.
if error !=nil, reconnectAttempts < maxReconnectAttempts {

Recouse · 2026-02-24T21:53:13Z

Turns out it requires an overhaul of the DataTask implementation. I also wanted to reduce the Mutex count, and either switch to a single state value or make DataTask an actor. I think it will be better to put this PR on hold and return to it later.

dogo · 2026-02-25T10:51:58Z

Turns out it requires an overhaul of the DataTask implementation. I also wanted to reduce the Mutex count, and either switch to a single state value or make DataTask an actor. I think it will be better to put this PR on hold and return to it later.

That makes sense. I agree the current approach introduces complexity in state management and reconnection flow.

Switching DataTask to an actor sounds like a much cleaner solution and would eliminate the need for multiple mutexes.

I'm happy to put this PR on hold and revisit it with a redesigned implementation.

dogo · 2025-10-01T11:11:00Z

• Implement exponential backoff reconnection with configurable limits (maxReconnectAttempts, reconnectInitialDelay, reconnectBackoffFactor)
• Track reconnect attempts and readyState using thread-safe Mutex; reset attempts on successful .open

• Implement exponential backoff reconnection with configurable limits (maxReconnectAttempts, reconnectInitialDelay, reconnectBackoffFactor) • Track reconnect attempts and readyState using thread-safe Mutex; reset attempts on successful .open

dogo · 2025-11-12T15:21:01Z

Hey @Recouse, I’ve resolved the conflicts and the CI has passed. Could you please review the code when you have a moment?

dogo · 2026-02-20T22:20:26Z

Hi @Recouse 👋

Before moving forward with this PR, I just wanted to check if there’s still interest in the feature it introduces. If not, no worries at all, I’m happy to close it. Just let me know 🙂

…connect

Recouse · 2026-02-21T09:19:23Z

Hi,
Yes, I’m interested in this feature. It had reconnection support in earlier versions, but I removed it because the implementation was unstable.

Recouse

Have you tested the implementation? At first glance, it looks fine, but there may be some caveats with SessionDelegate and URLSession instances from the initial request.

Recouse · 2026-02-21T09:23:01Z

+ /// Helper method for reconnection
+ private func attemptReconnect(stream continuation: AsyncStream<EventType>.Continuation) {
+ let delay = reconnectInitialDelay * pow(reconnectBackoffFactor, Double(reconnectAttempts - 1))
+ DispatchQueue.global().asyncAfter(deadline: .now() + delay) { [weak self] in


Would it possible to implement this with Task.sleep()?

Recouse · 2026-02-21T11:21:48Z

 /// it can be started by iterating event stream returned by ``DataTask/events()``.
 final class DataTask: Sendable {
+ /// Initializes or reinitializes the SSE session
+ private func startSession(stream continuation: AsyncStream<EventType>.Continuation) {


It's more of a stylistic request to declare methods after init()

dogo · 2026-02-23T11:54:08Z

Hi, Yes, I’m interested in this feature. It had reconnection support in earlier versions, but I removed it because the implementation was unstable.

Yes, I’ve tested the reconnection flow with:

normal connection
forced network drop
server-side close
manual cancellation

The session is properly invalidated before creating a new one, and the delegate is not reused across sessions to avoid unexpected behavior.

Recouse

In my tests I've noticed that the current logic relies on the URLSession:task:didCompleteWithError: delegate method to complete the request. I've added an error != nil check to properly close the connection when reconnection is not needed.

There's another issue: reconnection happens indefinitely, because on reconnection readyState becomes .connecting, and after the first response it's set to .open and resets reconnectAttempts. As a result, the request never finishes and re-runs indefinitely.

Recouse · 2026-02-24T21:23:23Z

+ // Attempts to reconnect if the limit has not been exceeded
+ if reconnectAttempts < maxReconnectAttempts {


Suggested change
// Attempts to reconnect if the limit has not been exceeded
if reconnectAttempts < maxReconnectAttempts {
// If an error occurred, an error object will indicate how the request failed, otherwise nil.
// Attempts to reconnect on error if the limit has not been exceeded.
if error !=nil, reconnectAttempts < maxReconnectAttempts {

Recouse · 2026-02-24T21:53:13Z

Turns out it requires an overhaul of the DataTask implementation. I also wanted to reduce the Mutex count, and either switch to a single state value or make DataTask an actor. I think it will be better to put this PR on hold and return to it later.

dogo · 2026-02-25T10:51:58Z

Turns out it requires an overhaul of the DataTask implementation. I also wanted to reduce the Mutex count, and either switch to a single state value or make DataTask an actor. I think it will be better to put this PR on hold and return to it later.

That makes sense. I agree the current approach introduces complexity in state management and reconnection flow.

Switching DataTask to an actor sounds like a much cleaner solution and would eliminate the need for multiple mutexes.

I'm happy to put this PR on hold and revisit it with a redesigned implementation.

dogo requested a review from Recouse as a code owner October 1, 2025 11:11

Merge remote-tracking branch 'upstream/main' into feature/reconnect
38d9edb

Merge branch 'main' of github.com:Recouse/EventSource into feature/re…
0a21302
…connect

Recouse reviewed Feb 21, 2026
View reviewed changes

Use Task.sleep for reconnect delay and reorder methods after init
9b134e8

Recouse reviewed Feb 24, 2026
View reviewed changes

dogo requested a review from Recouse as a code owner October 1, 2025 11:11

Merge remote-tracking branch 'upstream/main' into feature/reconnect
38d9edb

Merge branch 'main' of github.com:Recouse/EventSource into feature/re…
0a21302
…connect

Recouse reviewed Feb 21, 2026
View reviewed changes

Use Task.sleep for reconnect delay and reorder methods after init
9b134e8

Recouse reviewed Feb 24, 2026
View reviewed changes

dogo requested a review from Recouse as a code owner October 1, 2025 11:11

Merge remote-tracking branch 'upstream/main' into feature/reconnect
38d9edb

Merge branch 'main' of github.com:Recouse/EventSource into feature/re…
0a21302
…connect

Recouse reviewed Feb 21, 2026
View reviewed changes

Use Task.sleep for reconnect delay and reorder methods after init
9b134e8

Recouse reviewed Feb 24, 2026
View reviewed changes

dogo requested a review from Recouse as a code owner October 1, 2025 11:11

Merge remote-tracking branch 'upstream/main' into feature/reconnect
38d9edb

Merge branch 'main' of github.com:Recouse/EventSource into feature/re…
0a21302
…connect

Recouse reviewed Feb 21, 2026
View reviewed changes

Use Task.sleep for reconnect delay and reorder methods after init
9b134e8

Recouse reviewed Feb 24, 2026
View reviewed changes

dogo requested a review from Recouse as a code owner October 1, 2025 11:11

Merge remote-tracking branch 'upstream/main' into feature/reconnect
38d9edb

Merge branch 'main' of github.com:Recouse/EventSource into feature/re…
0a21302
…connect

Recouse reviewed Feb 21, 2026
View reviewed changes

Use Task.sleep for reconnect delay and reorder methods after init
9b134e8

Recouse reviewed Feb 24, 2026
View reviewed changes

dogo requested a review from Recouse as a code owner October 1, 2025 11:11

Merge remote-tracking branch 'upstream/main' into feature/reconnect
38d9edb

Merge branch 'main' of github.com:Recouse/EventSource into feature/re…
0a21302
…connect

Recouse reviewed Feb 21, 2026
View reviewed changes

Use Task.sleep for reconnect delay and reorder methods after init
9b134e8

Recouse reviewed Feb 24, 2026
View reviewed changes

dogo requested a review from Recouse as a code owner October 1, 2025 11:11

Merge remote-tracking branch 'upstream/main' into feature/reconnect
38d9edb

Merge branch 'main' of github.com:Recouse/EventSource into feature/re…
0a21302
…connect

Recouse reviewed Feb 21, 2026
View reviewed changes

Use Task.sleep for reconnect delay and reorder methods after init
9b134e8

Recouse reviewed Feb 24, 2026
View reviewed changes

dogo requested a review from Recouse as a code owner October 1, 2025 11:11

Merge remote-tracking branch 'upstream/main' into feature/reconnect
38d9edb

Merge branch 'main' of github.com:Recouse/EventSource into feature/re…
0a21302
…connect

Recouse reviewed Feb 21, 2026
View reviewed changes

Use Task.sleep for reconnect delay and reorder methods after init
9b134e8

Recouse reviewed Feb 24, 2026
View reviewed changes

		// Attempts to reconnect if the limit has not been exceeded
		if reconnectAttempts < maxReconnectAttempts {

- // Attempts to reconnect if the limit has not been exceeded
- if reconnectAttempts < maxReconnectAttempts {
+ // If an error occurred, an error object will indicate how the request failed, otherwise nil.
+ // Attempts to reconnect on error if the limit has not been exceeded.
+ if error !=nil, reconnectAttempts < maxReconnectAttempts {

Uh oh!

Conversation

dogo commented Oct 1, 2025

Uh oh!

dogo commented Nov 12, 2025

Uh oh!

dogo commented Feb 20, 2026

Uh oh!

Recouse commented Feb 21, 2026

Uh oh!

Recouse left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dogo commented Feb 23, 2026

Uh oh!

Recouse left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Recouse commented Feb 24, 2026

Uh oh!

dogo commented Feb 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

dogo commented Oct 1, 2025

Uh oh!

dogo commented Nov 12, 2025

Uh oh!

dogo commented Feb 20, 2026

Uh oh!

Recouse commented Feb 21, 2026

Uh oh!

Recouse left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dogo commented Feb 23, 2026

Uh oh!

Recouse left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Recouse commented Feb 24, 2026

Uh oh!

dogo commented Feb 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants