Publish on graceful disconnect

[daenney]

Is your feature request related to a problem? Please describe.

As part of using the MQTT integration in Home-Assistant, I want to signal the unavailability of a device when I disconnect. This requires publishing a payload to a specific topic.

I'm using the LWT for this, but LWT is only triggered for ungraceful disconnects. However, when the context is cancelled, Paho has no facility to publish extra messages during a graceful disconnect.

Describe the solution you'd like

I'd like to have something like OnClientDisconnect, similar to OnClientError, but that only triggers for graceful disconnect. This function should execute as the last thing before the connection to the broker is closed.

Describe alternatives you've considered

I'm currently setting the DisconnectPacketBuilder to a function that always returns nil. This causes every disconnect to be ungraceful from the broker's perspective and thus results in the LWT always getting sent. This feels hacky and unintended.

[MattBrittan]

Your approach of returning nil from DisconnectPacketBuilder seems reasonable to me, you could also send a DISCONNECT with a non-zero reason code. I'm open to a PR that adds a OnClientDisconnect type function, but this would require some care (because various go routines, such as incoming are terminated when the context is cancelled meaning things like publishing a QOS1+ message may not work as expected).

[daenney]

The thing is though, if I ctrl-c or otherwise gracefully terminate the program, that's semantically a success. So simply returning nil here feels a bit icky, and a non-zero reason code also sort of feels wrong?

I've been looking a bit, and I spotted a reason code "0x04" which states "Disconnect with Will Message." That feels appropriate for this use case, but I'm not entirely clear what that's intended for?

[MattBrittan]

which states "Disconnect with Will Message." That feels appropriate for this use case, but I'm not entirely clear what that's intended for?

Well the description in the spec is "The Client wishes to disconnect but requires that the Server also publishes its Will Message." so sounds a match for your requirements.

Whilst you could add a callback and publish a message, it seems cleaner to rely on the Will Message because that way the message will be sent regardless of how the disconnection occured (and gain the benefit of functionality like the Will Delay Interval). Of course you could also wrap the cancellation of the context such that a message is published before the context passed into paho is cancelled (this may be cleaner than using a callback).

[daenney]

Yeap, I was thinking about wrapping the context as well. I think that solves it too, avoiding the need to add something to the library.

Instead of implementing the OnClientDisconnect, I can send a PR with a few additional examples so there's a reference for someone else in the future to look at?

[MattBrittan]

Instead of implementing the OnClientDisconnect, I can send a PR with a few additional examples so there's a reference for someone else in the future to look at?

Sure - examples are always apreciated. Always happy to find a solution outside of the library because this helpd keep the complexity down.

[daenney]

I've added an example in daenney@50a54a9 that shows both the DisconnectPacketBuilder and some context juggling to be able to publish at shutdown.

The CLA for the Eclipse Foundation presents a problem for me. It seems to require the use of a public email address to sign-off with, which I don't use for Git because it's a regular vector for abuse in my case. I'm also not entirely sure why the foundations wants my legal name or home address, things I definitely don't need to share when contributing to other projects that also use a DCO or have a CLA.

That said, I fully intended to upstream this and the file has the Eclipse license headers. So if someone who has the Eclipse CLA sorted wants to yoink it and do the upstreaming, have at it.

[MattBrittan]

Thanks, unfortunately the CLA is not something I can work around (I realise it can be painful but there are valid reasons for having it). The submission does not have to be under your main email address (any address you control should be fine as long as the commit is signed off by the address).