[API Proposal]: Code analyse rule that require passing of cancellation token

[jarlef]

Background and motivation

The rule CA2016 checks that any in scope cancellation token must be forwarded, but if the current method does not have a cancellation token there rule does result in a violation

public async Task Foo(CancellationToken token) 
{
  await SomeMethodThatAcceptsCancellationToken(); // CA2016 violation
}

public async Task Bar() 
{
  await SomeMethodThatAcceptsCancellationToken(); // no violation
}

This can be hard to identify that the cancellation token is not forwarded down the stack as it should have been since the second method does not accept a token as a input parameter. There should be a even more strict rule that requires the forwarding of the cancellation token or to use CancellationToken.None if the cancellation token is not need / available.

public async Task Bar() 
{
  await SomeMethodThatAcceptsCancellationToken(CancellationToken.None);
}

This will make it easier to maintain the code and also perform code reviews on the use of cancellation tokens if the code base.

API Proposal

public async Task Bar() 
{
  await SomeMethodThatAcceptsCancellationToken(); // CA20XX violation
}

API Usage

public async Task Bar() 
{
  await SomeMethodThatAcceptsCancellationToken(); // CA20XX violation
}

Alternative Designs

No response

Risks

No response

[ghost]

Tagging subscribers to this area: @dotnet/area-system-threading-tasks
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Background and motivation

The rule CA2016 checks that any in scope cancellation token must be forwarded, but if the current method does not have a cancellation token there rule does result in a violation

public async Task Foo(CancellationToken token) 
{
  await SomeMethodThatAcceptsCancellationToken(); // violation
}

public async Task Bar() 
{
  await SomeMethodThatAcceptsCancellationToken(); // no violation
}

This can be hard to identify that the cancellation token is not forwarded down the stack as it should have been since the second method does not accept a token as a input parameter. There should be a even more strict rule that requires the forwarding of the cancellation token or to use CancellationToken.None if the cancellation token is not need / available.

public async Task Bar() 
{
  await SomeMethodThatAcceptsCancellationToken(CancellationToken.None);
}

This will make it easier to maintain the code and also perform code reviews on the use of cancellation tokens if the code base.

API Proposal

public async Task Bar() 
{
  await SomeMethodThatAcceptsCancellationToken(); // CA20XX violation
}

API Usage

public async Task Bar() 
{
  await SomeMethodThatAcceptsCancellationToken(); // CA20XX violation
}

Alternative Designs

No response

Risks

No response

Author:	jarlef
Assignees:	-
Labels:	api-suggestion, area-System.Threading.Tasks
Milestone:	-

[stephentoub]

Thanks. This is largely a duplicate of #78397, which proposes a rule that async methods should accept a token. I'm less inclined to have a rule about calls that aren't passed a token and don't have one to pass, as that's really just a stylistic choice as to whether to use the implicit default token or the explicit default token with None.

[stephentoub]

duplicate of #78397