rspec/rules/S3216/csharp/rule.adoc

61 lines
2.2 KiB
Plaintext
Raw Normal View History

== Why is this an issue?
2021-04-28 16:49:39 +02:00
After an ``++await++``ed ``++Task++`` has executed, you can continue execution in the original, calling thread or any arbitrary thread. Unless the rest of the code needs the context from which the ``++Task++`` was spawned, ``++Task.ConfigureAwait(false)++`` should be used to keep execution in the ``++Task++`` thread to avoid the need for context switching and the possibility of deadlocks.
This rule raises an issue when code in a class library targeting .Net Framework ``++await++``s a ``++Task++`` and continues execution in the original calling thread.
The rule does not raise for .Net Core libraries as there is no ``++SynchronizationContext++`` in .Net Core.
=== Noncompliant code example
2021-04-28 16:49:39 +02:00
2022-02-04 17:28:24 +01:00
[source,csharp]
2021-04-28 16:49:39 +02:00
----
var response = await httpClient.GetAsync(url); // Noncompliant
----
=== Compliant solution
2021-04-28 16:49:39 +02:00
2022-02-04 17:28:24 +01:00
[source,csharp]
2021-04-28 16:49:39 +02:00
----
var response = await httpClient.GetAsync(url).ConfigureAwait(false);
----
ifdef::env-github,rspecator-view[]
'''
== Implementation Specification
(visible only on this page)
=== Message
Add ".ConfigureAwait(false)" to this call to allow execution to continue in any thread.
'''
== Comments And Links
(visible only on this page)
=== on 1 Jul 2015, 15:40:18 Ann Campbell wrote:
Note [~tamas.vajk] that because I anticipate FP's from this rule, I've turned it on in the Security profile but not in SonarQube Way. Unless you're good enough to tell if execution _must_ pick back up in the main thread & ignore those instances?
=== on 2 Jul 2015, 07:02:20 Tamas Vajk wrote:
\[~ann.campbell.2] Thanks, it looks good. We'll see the FPs: we can automatically exclude "exe" projects, ...
=== on 21 Aug 2015, 06:18:04 Tamas Vajk wrote:
\[~ann.campbell.2] Do you think this is a security issue as well?
=== on 21 Aug 2015, 12:24:45 Ann Campbell wrote:
\[~tamas.vajk] I'm kinda in a bind: Critical rules must be bugs or security-related. Since multi-threading issues can affect security, I added the security tag rather than downgrading the severity.
=== on 21 Aug 2015, 12:28:28 Tamas Vajk wrote:
\[~ann.campbell.2] I see. It's more like a bug rule, but it is just a potential bug, so maybe we should reduce the severity to major.
=== on 21 Aug 2015, 12:50:53 Ann Campbell wrote:
Done [~tamas.vajk]
endif::env-github,rspecator-view[]