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
Extend the API of EventSource to specify what to do in the event of a ConnectionError.
Motivation
The primary advantage of Server Sent Events (SSE) is that the browser manages connectivity. While it mostly does this well, it turns out that a "503 - Service Unavailable" causes a ConnectionError, at least in Chrome. Other browsers may exhibit other behavior. A 503 is often a temporary condition so I have ended up coding up a retry with, for example, a delay of at least one second, and then a random 2, 3, 4, or 5 more seconds. Having the EventSource provide this as a built-in feature would cater for this common scenario and save the user a reasonable amount of code, which is compounded by dealing ConnectionError appearing for all message type subscriptions.
Detailed Explanation
I'm thinking that a new constructor could be provided:
pubenumConnectionStrategy{/// Retry with exponential backing off between a min and max durationRetryWithBackoff(Duration,Duration),/// Existing behaviorNone,}
Drawbacks, Rationale, and Alternatives
An implication would be an additional dependency on gloo-timers.
Unresolved Questions
Nothing at this stage.
The text was updated successfully, but these errors were encountered:
Summary
Extend the API of
EventSource
to specify what to do in the event of aConnectionError
.Motivation
The primary advantage of Server Sent Events (SSE) is that the browser manages connectivity. While it mostly does this well, it turns out that a "503 - Service Unavailable" causes a
ConnectionError
, at least in Chrome. Other browsers may exhibit other behavior. A 503 is often a temporary condition so I have ended up coding up a retry with, for example, a delay of at least one second, and then a random 2, 3, 4, or 5 more seconds. Having theEventSource
provide this as a built-in feature would cater for this common scenario and save the user a reasonable amount of code, which is compounded by dealingConnectionError
appearing for all message type subscriptions.Detailed Explanation
I'm thinking that a new constructor could be provided:
where
ConnectionStrategy
could be:Drawbacks, Rationale, and Alternatives
An implication would be an additional dependency on gloo-timers.
Unresolved Questions
Nothing at this stage.
The text was updated successfully, but these errors were encountered: