During a network outage, we experienced a hang in the Dispose call of the ManagedMQTTClient at this location in the code. It's unclear precisely what happened to cause this situation other than the environmental situation which I just described: a network outage.
Steps to reproduce the behavior:
I expect the code to eventually timeout and/or toss a timeout exception as opposed to hanging indefinitely. Our software will restart the box if we notice something (like a bad network) has happened, but we also expected the underlying software to not hang during shutdown. This resulted in our product not successfully restarting the box and manual resets being required.
We could trap a timeout exception and handle it the best we can during shutdown, but we cannot hang indefinitely.
I managed to create a dump of the process that hung, and one of the threads showed this:

.
NA
NA
maybe we need to pull in Microsoft.Bcl.AsyncInterfaces and make the ManagedClient AsyncDisposable?
I have motivation for this fix. Would you want me to try making this change and doing a PR?
Isn't it enough to use a SpinWait instead of Task.WaitAny? Or we can get rid of the wait at all. Why do we care if this task has completed first? The task implementation has proper exception handling and should exit without any issues. 馃
same behavior occured when i try call StopAsync() with down network interface.
We are facing similar issue with ManagedMQTTClient.StopAsync and it stuck forever. I am using version 3.0.13
Please try again with RC8. I added a timeout where the DISCONNECT packet is sent (which fails due to network issues).
Most helpful comment
maybe we need to pull in Microsoft.Bcl.AsyncInterfaces and make the ManagedClient AsyncDisposable?