Should SteamKit use .ConfigureAwait(false) everywhere?

[RudeySH]

I just ran into a deadlock issue because I had written synchronous code that was blocking on async code. I was accessing a Task's .Result properly in a synchronous method, instead of using Task.Run(...) or async/await (which is what solved my issue).

The deadlock issue started happening after updating my year-old SteamKit dependency to the latest version. My synchronous code was waiting (blocking) on async code which was invoking a method on WebAPI.AsyncInterface, which is where the deadlock occurred.

Before I decided to bite the bullet and make all my application code use async/await properly, I attempted to solve the deadlock by using .ConfigureAwait(false) on every single await. However, in order for this "solution" to work, .ConfigureAwait(false) must be used in third party code as well (in my case, SteamKit code).

Right now, it appears SteamKit uses .ConfigureAwait(false) inconsistently. I was able to find 7 instances of .ConfigureAwait(false) and a dozen or so awaits that aren't configured. 7 months ago, the following commit added an await without .ConfigureAwait(false) on line 240 of WebApi.cs which likely caused my issue:

f20bf15#diff-adf184c604c4a0453aaf92c99d505cf9e7a99c692c241b02b8c0046c9741e553R240

Now, .ConfigureAwait(false) isn't a pretty solution, and if a consumer of SteamKit can prevent blocking on async code, they should always do that instead. However, sometimes you can't easily get rid of blocking (for example when using a legacy framework that wasn't really designed to be used with async/await). Many online resources suggest that libraries should basically always use .ConfigureAwait(false) (unless the library uses the synchronization context), here's two examples:

• https://stackoverflow.com/a/13489639/1185136
• https://medium.com/bynder-tech/c-why-you-should-use-configureawait-false-in-your-library-code-d7837dce3d7f

I'm hoping this discussion will grab the attention of the maintainers of this project. Do you agree that all instances of await in SteamKit's code should be using .ConfigureAwait(false)?

[azuisleet]

I do agree that ConfigureAwait is a pain, but the way that async/await is structured, it is impossible to avoid.

The solution here is indeed to ensure that all our await calls use ConfigureAwait(false).

[yaakov-h]

The easy answer is yeah, we probably should, or we should at least ensure that we're off any user-interactive SynchronizationContexts, such as with something like this.

SteamKit consumers generally run as command-line apps (its been a very long time since Vapor was relevant) so there is no SynchronizationContext / the default one uses the thread pool, and there's no problem.

The simplest thing to do though would be to turn on a Roslyn Analyzer that highlights the problem and bulk-fix it.

[JustArchi]

The simplest thing to do though would be to turn on a Roslyn Analyzer that highlights the problem and bulk-fix it.

I can recommend https://www.nuget.org/packages/ConfigureAwaitChecker.Analyzer - using it myself in all of my projects. It's a pain to add those configure awaits everywhere, but it's making it much easier with quick fixes and warnings.

[yaakov-h]

There’s also CA2007 now.