ConfigureAwait(false) in WebAPI controller

Question

Should SonarLint fire S3216 in an ASP.NET Web API controller? It seems that this rule is for desktop applications, in ASP.NET the context is totally different, there's no danger of deadlocks. Or am I missing something?

Answer 1

You should still use ConfigureAwait(false) in WebAPI when you don't need to capture the context.

ConfigureAwait controls whether to resume on the captured SynchronizationContext or not. It's true that this is a more painful issue in UI apps, but it's relevant everywhere there's a SynchronizationContext which is all UI apps and all asp.net apps.

In UI apps the resource SynchronizationContext manages is the single UI thread so you can deadlock if you block it. In asp.net apps the resource is the request context and you are able to deadlock on it as well.

You can avoid using ConfigureAwait in console applications or windows services, though it's still a good practice to keep using it where appropriate.

Answer 2

@VictorGrigoriu, we are only checking if the output kind of a compilation unit is a DLL or not, and we report issues only in DLLs. You are right that we report on cases when in a DLL you still need to switch back to the original context. In general it's a very hard thing to figure out, but we could add a check for top level web app assemblies. We need to come up with a good way to do that or disable the rule by default to not generate false positives.

I've created a ticket to track this problem: https://jira.sonarsource.com/browse/SLVS-790 .

Other options until we come up with a permanent solution: you can disable this rule locally on the given project if you feel it's an annoyance. To do that, you'll need to edit the project's ruleset file through "references/analyzers/open active rule set"