DelayRetryDuration not working as intended about dotnet-eventsource HOT 4 CLOSED

I think I see. If it's "after every event" then that means each connection was initially successful. It does reset the counter in that case - this was intended behavior, because we didn't want intermittent failures to cause increasingly long delays if they only happened once in a while.

I agree that this is still not quite right; if we want to avoid continuing to increase the backoff when things have been working correctly, we should probably have a time threshold, like only reset the counter if the connection has stayed good for X amount of time. Also, I think there is currently a flaw in the logic such that the backoff will not always be incremented even on failed connections. I'll look into this further.

Also, thanks for catching that null issue. I think that in actual use cases that string will not be null (it ultimately comes from StreamReader.ReadLine which can return a null on end of stream, but I think if the connection is closed we will get an I/O error first) but that's not the kind of thing we should rely on.

from dotnet-eventsource.

Hmm. Are you definitely using the latest release? The problem where MaybeWaitWithBackOff was being called without an await was fixed last month in version 3.1.2. You can see the current version of that line here.

from dotnet-eventsource.

For some reason I was using the code from 4da02fb commit, but the problem persists in 3.1.5 too. If the server disconnects after every event, _backOff.GetReconnectAttemptCount() will be always 0 (so actually there will be no delay), which may result in high CPU and network consumption.

I also noticed that if content == null NullReferenceException will be thrown. I'm not sure if it's a normal flow or not, but it looks a bit suspicious.

from dotnet-eventsource.

I believe both the "not increasing the delay after an immediately failed connection" issue and the NullReferenceException have been fixed in the 3.2.0 release.

from dotnet-eventsource.