Using umqtt.simple get random OSError -1 exceptions?

[Jibun-no-Kage]

Looking at the umqtt.simple source, line 180... notice that when res = b'' the code generates OSError(-1), this is in wait_msg(). But I am failing to understand why this is qualified a fatal error, i.e. generates an exception with no explanation? I am setting this error randomly when I call check_msg() in a main process loop. Appears to be completely random when it happens. I am not flooding the socket with messages, nor does it appear to be some type of memory issue.

[peterhinch]

In my experience developing mqtt_as this error never occurs in normal operation. mqtt_as treats it as evidence of a connection problem, disconnecting from broker and WiFi, then reconnecting from scratch.

I would question the integrity of the WiFi connection if this is happening frequently. RF interference, perhaps?

[Jibun-no-Kage]

Peter, thanks for the clarification... It was so vague I was wondering! Yes, it was typically interference in my case, so I just trap it and deal with it, since in my project potential interference is to be expected at times... hence using MQTT in the first place. :)

Looking at the code, there are more graceful ways to handle it, but the 'simple' module is all I need for a situational informational publish of some statistical data non-critical in this case, if I lose reporting for a few seconds or even a minute or so, no problem.

[bidrohini]

Catch the OSError in your main loop and attempt to reconnect:
try:
client.check_msg()
except OSError as e:
print(f"Connection error: {e}")
client.connect()

[Jibun-no-Kage]

@bidrohini Not sure what you are trying communicate... I knew and had know how to trap the result. What I was asking was why the result was only a simple error code, i.e. -1 when the socket returned b'' as a result. This result seemed to mask a greater issue, i.e. a bad or incomplete message transport... I believe the code could and should report in greater detail than '-1' why the error was generated.

[peterhinch]

A key requirement of MQTT is that it assumes a reliable transport layer (e.g. TCP). The link can be temporarily interrupted, but if a message is received it must be complete and correct.

If your transport layer violates that principle all bets are off.

[Jibun-no-Kage]

Oh yes... the possible ISO/OSI model points of failure are always applicable. If I had a dime for all the crazy layer 2 and layer 3 issues we had in the early days of virtualization for example (i.e. VMware, Hyper-V, KVM, etc.)!