All usages of async/await syntax should use "ConfigureAwait"

Throughout Elsa, because it is shared/reusable code which could be hosted in any one of a number of environments, any place where the await keyword is used, it should also use the .ConfigureAwait(false) method.

The reasons and problem by not doing this is described in depth in this article, but it could be summarised as: “If you are writing reusable/library code and wish to use async/await, then always use .ConfigureAwait(false) with your awaits. This will prevent accidental thread-deadlocking when the library is consumed in certain environments.”

// Bad example:
await DoTheThingAsync();

// Good example:
await DoTheThingAsync().ConfigureAwait(false);

Consequences/symptom

As eluded to above, in some environments - such as those which have a concept of “a UI thread”, not using ConfigureAwait can cause an unwanted deadlock on the main (UI) thread. That will manifest as the whole application hanging and entering an indefinitely deadlocked state. Unfortunately it is not always possible to ‘fix’ this problem from the consuming app. It is far better to ‘fix it’ from the library.

[hankovich]

Who am I to argue with Mr. Toub? 😊

I’m 99% percent sure you’re right and nobody will set it to true, so I’m ok to follow yagni here.

The next question is, how do you force developers to use ConfigureAwait everywhere? I see two options:

1. Voodoo magic provided by Fody (https://github.com/Fody/ConfigureAwait) that will just automatically add it to all awaits.
2. Play with verbosity of the inspection CA2007.

I guess which option you will choose 😊

[sfmskywalker]

Well, consider me schooled. Turns out I knew even less than I already thought I did. 😅

@craigfowler Thank you for providing that excellent resource! I haven’t read everything in detail yet, but after skimming over it (including the referenced GitHub issues at the end) I still agree that it’s best if Elsa follows this pattern.

@hankovich I’m curious to hear your thoughts too after reading Stephen’s FAQ. We can of course consider following CSharpFunctionExtension’s example of reducing the ConfigureAwait(false) noise with an extension. Although I don’t see any benefits to allowing the flag to be configurable, given Stephen’s explanation on why it’s pretty much useless to ever set this to true.