Unhandled ConnectionRefusedError about gmqtt

[d21d3q]

Hmmm, my use case is to embed mqtt client in IoT device and let it go into the wild, and report some data.
In such case I would except from program (device), to warn me about bad configuration, but keep retrying to connect without crashing. I am configuring device once (asserting that it is working), and letting him live its own life (like gps trackers :) ).
But there are other factors that might fail and device should not care about them. Imagine that your device reboots during such conditions

• broker goes offline (crash/update) - it is temporary unavailable, but connect fails due to ConnectionRefusedError
• network goes down - temporarily, but connect fails due to socket.gaierror
• somebody deletes (mqtt) user credentails on server, and later restore them,

So if device reboots and goes through connect while one of above edge cases occur, then program would crash.
However when all exceptions on connect are handled and reconnect is manually rescheduled then it works (as suggesed).
That is why I am suggesting that connect should reconnect automatically but notify rest of program about connection failure through some callback.

[Lenka42]

Hey @d21d3q
I added kwarg raise_exc=True to client.connect method. Together with unlimitted reconnects this should work in your case. LEt me know if it helps 🙂

[NICOLASGON]

http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718033

If a server sends a CONNACK packet containing a non-zero return code it MUST then close the Network Connection [MQTT-3.2.2-5]

gmqtt doesn't implement the MQTT standard for this particular point.

[Lenka42]

Actually this is expected behavior. Reconnects are good when you client is working, but connection at the moment becomes broken and after some time your client automatically reconnects. If the first connection attempt was unsuccessful, it probably means that configuration is bad, host, port or authorization method should be fixed.

[skewty]

@d21d3q does this resolve your problem? Can this issue be closed?

[d21d3q]

I will have a look at it on Monday. Thank you.

[mfrlin]

No, this is not the correct way of handling this. If you take a look at the reconnect function you will see that it handles OSError and connect function does not. This is why the client explodes when broker is not online and you try to connect.

Workaround is something like this:

client = MQTTClient("client_id")
while True:
    try:
        await client.connect(broker_host)
    except OSError:
        print(f'Can not connect to the broker at {broker_host}')
        await asyncio.wait([asyncio.sleep(5), STOP.wait()], return_when=asyncio.FIRST_COMPLETED)
        if STOP.is_set():
            sys.exit()
    else:
        break

await STOP.wait()
await client.disconnect()

[Lenka42]

@NICOLASGON Specification tells server must close the connection after it sends bad CONNACK package. gmqtt is about client relaization and docs do not specify any required actions after receiving bad connack code.

[mfanara]

@Lenka42 - Using the current master branch (as of 25 FEB 2022), what is the correct answer?

This works:

try:
await lLocalMRClient.connect("localhost", 1884, keepalive=60)
except ConnectionRefusedError:
asyncio.ensure_future(lLocalMRClient.reconnect(delay=True))

as does:

try:
await lLocalMRClient.connect("localhost", 1884, keepalive=60, raise_exc=True)
except:
asyncio.ensure_future(lLocalMRClient.reconnect(delay=True))

And I see above the suggestion to catch OSError