Open pjcdawkins opened 1 year ago
Sorry I was confused by the server implementation I was using... and by the default MaxElapsedTime
on the backoff strategy, which causes the loop to end silently after 15 minutes, which maybe could be an issue for this library but a separate one.
Despite other bugs distracting me, I believe this is still an issue (despite MaxElapsedTime=0), and I can reproduce it with a handwritten server which simply closes the response writer (return
from the http handler).
Perhaps the library's own server implementation doesn't ever do that... I want this to work with a server that does. (Really the main thing I want is to have a client that will reconnect (after backoff) on any error, or at least one that won't stop silently.)
(Thanks for a great library)
This is almost a duplicate of #75 depending if you treat the current behavior as a bug or a feature
Thanks @pjcdawkins I got stuck on this but thankfully you had already figured it out. Hoping these will get merged, pulling your PRs in manually for now.
Just a note that I ran into the same issue. If the server is restarted for whatever reason, you'd expect the client to reconnect. This isn't happening if the server stopped by closing the connection nicely as it returns an EOF. Definitely a bug in my use-case.
https://github.com/r3labs/sse/blob/c6d5381ee3ca63828b321c16baa008fd6c0b4564/client.go#L217
It seems on EOF, the error is ignored and the read loop silently finishes, without an error, so backoff.RetryNotify does not retry.
If this EOF check is removed (so
err
is returned unconditionally), the clientbehaves as I would expect: it reconnects after an EOF[edit: currently unsure about this].What is the intended/expected behavior here?