Handle connection errors

[Ilia Rodionov]

Hello. I'm trying to use a centrifuge to create a simple chat and can't think of a better way to handle connection errors (for example, the user has no internet or the server is not available). Is there any way to do this?

[Alexander Emelin]

@LamaMen hi, all other Centrifugo clients expose Disconnect event if the initial connect failed, but centrifuge-dart does not - it just tries to reconnect in the background. I think we should mimic this behaviour here too.

Do I understand right that your question is about handling errors on initial connect to the server?

[Ilia Rodionov]

Yes!))

[Alexander Emelin]

@LamaMen hi, trying to address this and some other things in #57 – try to play with console/example.dart from that branch - does it makes sense or you still need sth else?

[Ilia Rodionov]

Hi, I looked at what you changed and I have a couple of questions:

• It is not entirely clear why this method cannot be added to the client interface: bool get connected => _state == _ClientState.connected;
• As I understand it, we can set a callback (config.retry()) that will be called on every reconnection and use it to handle these cases. But the question is, how can we figure out what was the reason for the reconnection? Or is it better to use streams disconnectStream and errorStream for the reasons of reconnection?

And one more question, is it possible to transfer these changes to the version of the library without support null safty (for example v0.5.1)? We use an old version of flutter sdk on our project (v1.22.6).

[Alexander Emelin]

It is not entirely clear why this method cannot be added to the client interface: bool get connected => _state == _ClientState.connected;

The reason it's not exposed is that nobody asked about it and I had no use case for it personally. If you need it to be exposed describe your use case. In most cases you better listen to state changes using connect/disconnect events and update application state instead of checking for connected status before operations. But I may miss sth here since it's hard to have all possible apps/use cases in mind.

As I understand it, we can set a callback (config.retry()) that will be called on every reconnection and use it to handle these cases. But the question is, how can we figure out what was the reason for the reconnection? Or is it better to use streams disconnectStream and errorStream for the reasons of reconnection?

config.retry is mostly for changing reconnect time strategy, disconnect reason can be found from disconnect event, and you can log errors from errorStream to investigate the exact error happening. Disconnect reason does not have exact detailed error description, it acts more like enum with some predefined values why the connection state changed. There are some plans to standartize disconnects a bit throughout Centrifugo(e) ecosystem: tracked in centrifugal/centrifuge#149 - but cant give any ETAs for it.

Maybe you will have better ideas on the more handy error/disconnect handling strategy – we can discuss this!

is it possible to transfer these changes to the version of the library without support null safty

I won't backport this myself, but if you are interested in migrating some of the later added features into 0.5.x then I can help creating a 0.5.x branch, merge pr with backwards compatible changes into it and release.

[Alexander Emelin]

Addressed by v0.8.0. Disconnect now fired on initial connect error and Client.errorStream added to log connection errors.

Closing, @LamaMen feel free to comment though – if you have ideas, suggestions on how we can improve API further we can continue discussion here.

[Ilia Rodionov]

Hi, I'm sorry I didn't answer for so long. I would still ask for your help to make a backport. I just haven't done this yet))

[Mikhail Kalinin]

Why is Centrifuge's websocket used for mobile app instead of PUSH?