Too many UnobservedTaskException

[nelsoncvjr-stone]

Too many UnobservedTaskException

[nelsoncvjr-stone]

Thanks for your attention @madelson!

[madelson]

@nelsoncvjr-stone thanks for the detailed report!

return new LockHandlerToken(handler, handler.HandleLostToken);

By accessing HandleLostToken you're forcing the library to start proactively tracking the state of the underlying connection. However, it's not obvious from your code that you actually need this. I would suggest either removing the wrapper class or making the wrapper class access the token lazily so that you only pay this price when you are actually going to use the HandleLostToken in your caller.

I would like to know if this behavior is by design/expected by lib or not?

So far, I have not made "avoid UnobservedTaskException" a design constraint for this library. There are cases where the library spins off background tasks that could fail under normal conditions such as monitoring connection drops which might get interrupted by the application's desire to release the lock (and therefore close the connection).

In many cases, I've endeavored to minimize the overhead of thrown exceptions via an internal TryAwait() method. However, this issue revealed to me that TryAwait() was not properly observing the exception so it would still get reported as unobserved.

I've pushed a fix for that issue to the release-2.4 branch; it will be included in the next release of the library.

That said, I have not audited the entire library for other cases where UnobservedTaskException might fire spuriously; I'd welcome issues that identify more scenarios though.