Closed jangruenwaldt closed 6 months ago
I too am having the same issue. My event stream URL becomes invalid when the underlying event finishes (sporting match). I need the http status code to be readable to determine when to stop initiating the event stream, or maybe disable autoreconnect if http status code = 404.
Great package BTW!
Hey @jangruenwaldt @gwsingo,
thanks for pointing this issue.
As i am afk this weekend, I’ll fix this issue and there should be a new update in a week.
Hey thank you so much!
As an enhancement I would like the possibility of changing the header used between connections if possible. Maybe a callback of "reconnecting" with a new headers as a parameter?
Cheers again!
This would be a new issue to track, but any reason why the initial header and reconnect header would be different?
Yes, indeed. When connecting the event stream sends the last 3-4 events if in the middle of the game. Subsequent headers have a 'Last-Event-Id' header to tell the server what event id the client has processed up to. The Last-Event-Id can be kept track of in the app, but I need to duplicate what is being sent to the event server in the request headers.
An accessible headers property that can be changed while listening would solve the issue.
Thanks again!! :-)
Hello there again. Have you been able to look at myself & jangruenwaldt issue with the onError: not firing and not auto reconnecting if there's a http response code >= 400?
My app is working flawlessly except for this issue. I want to submit my app to the store in the next few days.
If you could look at it soon it would be very much appreciated.
Thanks again!! ;-)
Hey @gwsingo @jangruenwaldt,
First of all I'd like to say sorry. Due to some family issues, I wasn't able to take a look at this issue.
That being said, I've found the root cause. I'll be pushing the fix in few hours.
The said fix will resolve onError
not getting triggered when we receive any status code that's not 200.
Now if you get any status code, that's not 200, you'll get this message.
Connection Error Status:${data.statusCode}, Connection Error Reason: ${data.reasonPhrase}
Hey @gwsingo @jangruenwaldt,
Version 1.6.9 has the fix and It's out now.
Just to summarise,
onError
callback method will be triggered when you receive any non 2xx status code. Connection Error Status:${data.statusCode}, Connection Error Reason: ${data.reasonPhrase}
.Feel free to reopen this issue if you face any issues. Happy to jump back on it again.
Hey @gwsingo @jangruenwaldt,
First of all I'd like to say sorry. Due to some family issues, I wasn't able to take a look at this issue.
That being said, I've found the root cause. I'll be pushing the fix in few hours.
The said fix will resolve
onError
not getting triggered when we receive any status code that's not 200.
First of all, an apology is not required, family is the most important thing in our lives, so they take priority. Secondly, thank you for fixing. this will help greatly.
Edit: I cant reproduce it now, leave this issue closed for now.
Thanks a lot! Definitely no problem if it takes a long time, there are more important things.
Unfortunately, I still face another problem, which is when the connection never gets established, onError handler is also not called. An example:
flutter: SSE Error: ClientException: Connection closed before full header was received, uri=(a valid url)
[EventFlux] ℹ️ Disconnecting
[EventFlux] ℹ️ Disconnected
[EventFlux] ℹ️ Disconnecting
[EventFlux] ℹ️ Disconnected
The onError handler should always be called when the connection does not succeed, because otherwise the connection is lost, and important events are missed.
Hi,
thanks for a great package! However, I am facing an issue:
After 504 or 401 status code is returned from server, the onError handler I provided is not called, therefore my connection is disconnected and lost forever. Furthermore, I need access to the status code, so I can take action according to my server response.
My code is as follows:
Thanks!
Edit: Just found out onConnectionClose can be used to avoid this behaviour - but shouldn't onError still be called?