-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
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
dotnet-policy-service
bot
added
the
untriaged
New issue has not been triaged by the area owner
label
Aug 26, 2024
Tagging subscribers to this area: @dotnet/area-system-threading-tasks |
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
bot
added
the
in-pr
There is an active PR which will close this issue when it is merged
label
Aug 27, 2024
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
Tagging subscribers to this area: @dotnet/area-system-datetime |
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]>
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
Description
When using
TimeProviderTaskExtensions
from down-level runtimes, the Delay method which accepts aCancellationToken
behaves inconsistently with the equivalentTask.Delay
overload.Task.Delay
checksCancellationToken.IsCancellationRequested
first, whereasTimeProviderTaskExtensions.Delay
checks the timeout forTimeSpan.Zero
first. This means if the method is passed a zero timeout and an already canceledCancellationToken
,Task.Delay
returnsTask.FromCanceled
whereasTimeProviderTaskExtensions.Delay
returnsTask.CompletedTask
.runtime/src/libraries/Microsoft.Bcl.TimeProvider/src/System/Threading/Tasks/TimeProviderTaskExtensions.cs
Lines 69 to 77 in fb8e078
runtime/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs
Lines 5725 to 5729 in 9a31a5b
The same problem also affects
TimeProviderTaskExtensions.WaitAsync
.runtime/src/libraries/Microsoft.Bcl.TimeProvider/src/System/Threading/Tasks/TimeProviderTaskExtensions.cs
Lines 164 to 172 in 9a31a5b
runtime/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs
Lines 2837 to 2845 in 9a31a5b
Reproduction Steps
Target .NET < 8.0 (such as 4.6.2) and use a non-system time provider.
and
Expected behavior
The examples above should throw
OperationCanceledException
o for consistency, otherwise library authors converting their code to useTimeProvider
may encounter unexpected behaviors.Actual behavior
The
Delay
example above completes without an exception, theWaitAsync
example throwsTimeoutException
.Regression?
This is not a regression
Known Workarounds
Call
CancellationToken.ThrowIfCancellationRequested()
manually before callingDelay
orWaitAsync
. However, there is still a slim chance of a race condition in this case.Configuration
No response
Other information
No response
The text was updated successfully, but these errors were encountered: