Open robert197 opened 4 months ago
Client version: github.com/eclipse/paho.golang v0.10.1-0.20220826012857-d63b3b28d25f
That version is two years old; please try with master
(or, at a minimum, v0.21
). I know I've made a range of changes to the error handling in the interim.
@MattBrittan Thanks for the info, I have updated the version to v0.21
but the behavior is still the same.
Thanks. The changes I was thinking of were in autopaho
- see the errorHandler
, this ensures only a single error is passed through (paho
sometimes raises multiple errors when the connection is lost).
paho
is intended to be a fairly low level library, and commonly returns multiple errors (as handled in by the above autopaho
code). I'm not really sure whether to class this as a bug, as I believe that the way this works was deliberate (the error handling in paho.mqtt.golang
led to quite a few deadlocks over the years, I'd guess this was a reaction to that). The documentation should definitely mention this...
When the Disconnect method is invoked with a specific reason code, the OnClientError callback is unexpectedly triggered with a net.ErrClosed error, even though the Disconnect operation itself returns nil. This suggests that the disconnection is being incorrectly treated as an error, potentially indicating an issue with how the library handles socket closures on client-initiated disconnects.
To reproduce
Configure the client with callbacks for server disconnections and client errors:
Disconnect the client using the Disconnect method with an administrative action reason code:
Expected behaviour:
The expected behavior is for the client to disconnect without invoking the OnClientError callback, as the disconnection is user-initiated and should not be treated as an error condition.
Software used:
MQTT Broker version: emqx:5.3.2 Client version: github.com/eclipse/paho.golang v0.10.1-0.20220826012857-d63b3b28d25f
Additional context
Currently, I am using a workaround that checks for net.ErrClosed in the OnClientError callback to differentiate between genuine errors and this disconnection handling issue. Here is the temporary code adjustment:
It seems there might be an issue with how the socket closure is managed during the disconnection process, perhaps attempting to close an already closed connection.