Question about proper CancellationToken usage within awaitable methods

[WizardBrony]

public Task Method1Async(CancellationToken token)
{
    if (token.IsCancellationRequested)
        return Task.FromCanceled(token);
    // ...
}

public Task Method2Async(CancellationToken token)
{
    token.ThrowIfCancellationRequested();
    // ...
}

Given the following common usage of awaitable methods:

var method2Task = Method2Async(token);
// ...
try
{
    await method2Task;
}
catch (OperationCanceledException)
{
    // ...
}

or since .NET 8.0:

var method2Task = Method2Async(token);
// ...
await method2Task.ConfigureAwait(ConfigureAwaitOptions.SuppressThrowing);

do the .NET design guidelines consider Method2Async as having a bug? I haven't seen any official statements, so links to relevant documentation would be appreciated.

[dotnet-policy-service]

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

[stephentoub]

do the .NET design guidelines consider Method2Async as having a bug?

Yes. All exceptions in Task-returning methods, other than argument validation, should emerge asynchronously via the returned Task rather than being propagated out synchronously.

[WizardBrony]

Yes. All exceptions in Task-returning methods, other than argument validation, should emerge asynchronously via the returned Task rather than being propagated out synchronously.

Thank you very much for confirming.

[julealgon]

do the .NET design guidelines consider Method2Async as having a bug?

Yes. All exceptions in Task-returning methods, other than argument validation, should emerge asynchronously via the returned Task rather than being propagated out synchronously.

@stephentoub can you clarify? That is only the case because the method lacks the async modifier, correct?

If it had async and some await in the body, token.ThrowIfCancellationRequested(); would be considered appropriate as it would be returned as part of the observed Task in that case.

[stephentoub]

do the .NET design guidelines consider Method2Async as having a bug?

Yes. All exceptions in Task-returning methods, other than argument validation, should emerge asynchronously via the returned Task rather than being propagated out synchronously.

@stephentoub can you clarify? That is only the case because the method lacks the async modifier, correct?

If it had async and some await in the body, token.ThrowIfCancellationRequested(); would be considered appropriate as it would be returned as part of the observed Task in that case.

My statement is about observable behavior. However it's implemented, that should be the observable behavior.

Using async/await is an implementation detail. And, yes, if you use async to implement a Task-returning method, all exceptions thrown from the body of the method will be stored into the returned Task rather than propagating out of the call synchronously.