The Ruby SSE implementation diverged from the standard LaunchDarkly SSE behavior, and from its own documentation, in two ways:
If you set the initial reconnect to delay to (for instance) 1.0, the first reconnection attempt should have used a delay between 0.5 and 1.0; instead, it used no delay, and the second attempt would use the correct initial delay.
Worse: if a successful connection remained open for at least reconnect_reset_interval (default 60 seconds), instead of correctly resetting to the initial delay for the next failure, it would reset to zero and continue with zero delay for every subsequent reconnect. In the case of a sustained network interruption or service outage, that would cause a spike in CPU usage as it attempted to reconnect in a tight loop.
This PR fixes both of those issues. Now, consistent with LaunchDarkly SDK streaming behavior in general (and with the existing documentation for this package), if the initial delay is set to N then the first reconnection attempt will be be in the range [N/2, N], and subsequent reconnections will continue increasing the delay exponentially unless at least reconnect_reset_interval has elapsed since the last success, in which case the next delay will start over at [N/2, N] and continue increasing as usual.
The Ruby SSE implementation diverged from the standard LaunchDarkly SSE behavior, and from its own documentation, in two ways:
If you set the initial reconnect to delay to (for instance) 1.0, the first reconnection attempt should have used a delay between 0.5 and 1.0; instead, it used no delay, and the second attempt would use the correct initial delay.
Worse: if a successful connection remained open for at least
reconnect_reset_interval(default 60 seconds), instead of correctly resetting to the initial delay for the next failure, it would reset to zero and continue with zero delay for every subsequent reconnect. In the case of a sustained network interruption or service outage, that would cause a spike in CPU usage as it attempted to reconnect in a tight loop.This PR fixes both of those issues. Now, consistent with LaunchDarkly SDK streaming behavior in general (and with the existing documentation for this package), if the initial delay is set to N then the first reconnection attempt will be be in the range [N/2, N], and subsequent reconnections will continue increasing the delay exponentially unless at least
reconnect_reset_intervalhas elapsed since the last success, in which case the next delay will start over at [N/2, N] and continue increasing as usual.