Getting a `MqttClient` struct before server is reachable.

[vincentdephily]

As far as I could tell, the only way to get a MqttClient struct is its start() method, but it fails if the server is not accessible.

This seems reasonable at first blush except it's inconsistent with the fact that rumqtt handles reconnection itself and can apparently stack pending publish() until connection succeeded. Mobile devices often have a flaky connection; rumqtt should handle connection issues at startup like it does at runtime.

[tekjar]

Can I know which branch you are using? master or v3? v3 has reconnection options to always retry. But it's still in development.

[vincentdephily]

I'm using master, though I saw that a lot of work is happening in v3. Should I be trying v3 instead ? I'm still in the initial stage of mqtt support, I haven't settled on a particular lib yet, I might even go for a codec-only lib and handle the network myself (using actix).

Master does reconnect at runtime and eventually honors the publish() that was failing while the server was down. It's the initial start() that doesn't handle an unreachable server.

I can work around this, but this forces me to sprinkle initialisation code throughout the runtime codepaths, which is very inelegant. And I can't afford to stall initialisation until the server is up.

[tekjar]

v3 is around 90% complete. Few more bugs to squash. It would also help me understand people's usecases. I would suggest you to please try v3 and give me a sample code of what's not working/ergonomic for you

[vincentdephily]

I've switched to the v3 branch.

I was going to say that my issue was still there, but I eventually figured out that I needed to set_reconnect_opts(ReconnectOptions::Always(_)). Maybe the start() function could document that ?

Also, I wonder if some connection errors could be identified as permanent errors (like "host not found" as opposed to "connection timeout") and considered fatal anyway ? Maybe this is too much policy to put in rumqtt, and we should instead get APIs to query the number of connection attempts and/or the last error ?

[tekjar]

Maybe the start() function could document that

I'll document these. Eventually :). Priority is to fix these issues to release v3.

Maybe this is too much policy to put in rumqtt, and we should instead get APIs to query the number of connection attempts and/or the last error ?

Yeah. We can revisit these once the core is stabilised

[tekjar]

Maybe this is too much policy to put in rumqtt, and we should instead get APIs to query the number of connection attempts and/or the last error ?

Yeah. This might be a diminished return for the effort and increase learning curve for users to understand the cases where rumqtt won't reconnect (even with AlwayReconnect options).