Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Down-level TimeProviderTaskExtensions CancellationToken behavior is inconsistent with Task #106996

Closed
brantburnett opened this issue Aug 26, 2024 · 2 comments · Fixed by #107009
Closed
Assignees
Labels
area-System.DateTime in-pr There is an active PR which will close this issue when it is merged tenet-compatibility Incompatibility with previous versions or .NET Framework
Milestone

Comments

@brantburnett
Copy link
Contributor

brantburnett commented Aug 26, 2024

Description

When using TimeProviderTaskExtensions from down-level runtimes, the Delay method which accepts a CancellationToken behaves inconsistently with the equivalent Task.Delay overload. Task.Delay checks CancellationToken.IsCancellationRequested first, whereas TimeProviderTaskExtensions.Delay checks the timeout for TimeSpan.Zero first. This means if the method is passed a zero timeout and an already canceled CancellationToken, Task.Delay returns Task.FromCanceled whereas TimeProviderTaskExtensions.Delay returns Task.CompletedTask.

if (delay == TimeSpan.Zero)
{
return Task.CompletedTask;
}
if (cancellationToken.IsCancellationRequested)
{
return Task.FromCanceled(cancellationToken);
}

private static Task Delay(uint millisecondsDelay, TimeProvider timeProvider, CancellationToken cancellationToken) =>
cancellationToken.IsCancellationRequested ? FromCanceled(cancellationToken) :
millisecondsDelay == 0 ? CompletedTask :
cancellationToken.CanBeCanceled ? new DelayPromiseWithCancellation(millisecondsDelay, timeProvider, cancellationToken) :
new DelayPromise(millisecondsDelay, timeProvider);

The same problem also affects TimeProviderTaskExtensions.WaitAsync.

if (timeout == TimeSpan.Zero)
{
return Task.FromException(new TimeoutException());
}
if (cancellationToken.IsCancellationRequested)
{
return Task.FromCanceled(cancellationToken);
}

if (cancellationToken.IsCancellationRequested)
{
return FromCanceled(cancellationToken);
}
if (millisecondsTimeout == 0)
{
return FromException(new TimeoutException());
}

Reproduction Steps

Target .NET < 8.0 (such as 4.6.2) and use a non-system time provider.

using var cts = new CancellationTokenSource();
cts.Cancel();

await new FakeTimeProvider().Delay(TimeSpan.Zero, cts.Token);

and

var tcs = new TaskCompletionSource<object>();

using var cts = new CancellationTokenSource();
cts.Cancel();

await tcs.WaitAsync(TimeSpan.Zero, new FakeTimeProvider(), cts.Token);

Expected behavior

The examples above should throw OperationCanceledException o for consistency, otherwise library authors converting their code to use TimeProvider may encounter unexpected behaviors.

Actual behavior

The Delay example above completes without an exception, the WaitAsync example throws TimeoutException.

Regression?

This is not a regression

Known Workarounds

Call CancellationToken.ThrowIfCancellationRequested() manually before calling Delay or WaitAsync. However, there is still a slim chance of a race condition in this case.

Configuration

No response

Other information

No response

@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Aug 26, 2024
Copy link
Contributor

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

@brantburnett brantburnett changed the title TimeProviderTaskExtensions.Delay CancellationToken behavior is inconsistent with Task.Delay Down-level TimeProviderTaskExtensions CancellationToken behavior is inconsistent with Task Aug 27, 2024
brantburnett added a commit to brantburnett/runtime that referenced this issue Aug 27, 2024
…sions

This makes the down-level behavior for Delay and WaitAsync match the
behavior in .NET 8 and later, prefering to return a Canceled task over
a Completed task or TimeoutException when the TimeSpan is Zero and the
CancellationToken is already Canceled.

Fixes dotnet#106996
@dotnet-policy-service dotnet-policy-service bot added the in-pr There is an active PR which will close this issue when it is merged label Aug 27, 2024
@ericstj ericstj added area-System.DateTime tenet-compatibility Incompatibility with previous versions or .NET Framework and removed area-System.Threading.Tasks untriaged New issue has not been triaged by the area owner labels Sep 4, 2024
@ericstj ericstj added this to the 9.0.0 milestone Sep 4, 2024
Copy link
Contributor

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

@tarekgh tarekgh closed this as completed in 36e6b42 Sep 5, 2024
github-actions bot pushed a commit that referenced this issue Sep 5, 2024
…sions

This makes the down-level behavior for Delay and WaitAsync match the
behavior in .NET 8 and later, prefering to return a Canceled task over
a Completed task or TimeoutException when the TimeSpan is Zero and the
CancellationToken is already Canceled.

Fixes #106996
ericstj pushed a commit that referenced this issue Sep 6, 2024
…TaskExtensions (#107416)

* Check CancellationToken before TimeSpan.Zero in TimeProviderTaskExtensions

This makes the down-level behavior for Delay and WaitAsync match the
behavior in .NET 8 and later, prefering to return a Canceled task over
a Completed task or TimeoutException when the TimeSpan is Zero and the
CancellationToken is already Canceled.

Fixes #106996

* Test improvements based on feedback

---------

Co-authored-by: Brant Burnett <[email protected]>
jtschuster pushed a commit to jtschuster/runtime that referenced this issue Sep 17, 2024
…dotnet#107009)

* Check CancellationToken before TimeSpan.Zero in TimeProviderTaskExtensions

This makes the down-level behavior for Delay and WaitAsync match the
behavior in .NET 8 and later, prefering to return a Canceled task over
a Completed task or TimeoutException when the TimeSpan is Zero and the
CancellationToken is already Canceled.

Fixes dotnet#106996

* Test improvements based on feedback

---------

Co-authored-by: Tarek Mahmoud Sayed <[email protected]>
sirntar pushed a commit to sirntar/runtime that referenced this issue Sep 30, 2024
…dotnet#107009)

* Check CancellationToken before TimeSpan.Zero in TimeProviderTaskExtensions

This makes the down-level behavior for Delay and WaitAsync match the
behavior in .NET 8 and later, prefering to return a Canceled task over
a Completed task or TimeoutException when the TimeSpan is Zero and the
CancellationToken is already Canceled.

Fixes dotnet#106996

* Test improvements based on feedback

---------

Co-authored-by: Tarek Mahmoud Sayed <[email protected]>
@github-actions github-actions bot locked and limited conversation to collaborators Oct 6, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.DateTime in-pr There is an active PR which will close this issue when it is merged tenet-compatibility Incompatibility with previous versions or .NET Framework
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants
@brantburnett @ericstj @tarekgh and others