DbCommand.ExecuteReaderAsync throws TaskCanceledException with wrong CancellationToken

[Coder3333]

I am witnessing this behavior in packages\netstandard.library\2.0.3\build\netstandard2.0\ref\netstandard.dll when running from a .Net Core 3.1 application.

When I call DbCommand.ExecuteReaderAsync with a CancellationToken and cancel it before it finishes, an exception is thrown that contains a TaskCanceledException buried down in the InnerExceptions. I expect that behavior, but the issue is that the TaskCanceledException.CancellationToken is not the CancellationToken that I provided to ExecuteReaderAsync. I do not know where this other CancellationToken is coming from, but I thought we were only supposed to suppress TaskCanceledException in our applications if it is for the provided CancellationToken, so I end up with a lot more unhandled exceptions than I want.

Is it safe to suppress any TaskCanceledException, no matter what CancellationToken it contains? Where does this mystery CancellationToken come from, and could ExecuteReaderAsync just return the CancellationToken given to it?

                using (var cts = new CancellationTokenSource())
                {
                    using (var cmd = db.GetSqlStringCommand(queryString))
                    {
                        cts.Cancel();
                        try
                        {
                            using (var rdr = cmd.ExecuteReaderAsync(cts.Token).Result)
                            {
                            }
                        }
                        catch (Exception ex3)
                        {
//  if you inspect ex3, you will find a TaskCanceledException buried in InnerExceptions, but its CancellationToken is not cts.Token
                            throw;
                        }
                    }
                }

Additional Comments:
I have tested this with "System.Data.SqlClient.SqlCommand" and "Microsoft.Data.SqlClient.SqlCommand". The result is the same in both cases where the TaskCanceledException holds a new CancellationToken and the TaskCanceledException is wrapped in an AggregateException, so I have to dig down in the exception stack to find the TaskCanceledException , which means I cannot just catch TaskCanceledException.

System.AggregateException: One or more errors occurred. (A task was canceled.)
---> System.Threading.Tasks.TaskCanceledException: A task was canceled.
--- End of inner exception stack trace ---
at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
at System.Threading.Tasks.Task1.GetResultCore(Boolean waitCompletionNotification) at System.Threading.Tasks.Task1.get_Result()

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

Issue Details

---

I am witnessing this behavior in packages\netstandard.library\2.0.3\build\netstandard2.0\ref\netstandard.dll when running from a .Net Core 3.1 application.

When I call DbCommand.ExecuteReaderAsync with a CancellationToken and cancel it before it finishes, an exception is thrown that contains a TaskCanceledException buried down in the InnerExceptions. I expect that behavior, but the issue is that the TaskCanceledException.CancellationToken is not the CancellationToken that I provided to ExecuteReaderAsync. I do not know where this other CancellationToken is coming from, but I thought we were only supposed to suppress TaskCanceledException in our applications if it is for the provided CancellationToken, so I end up with a lot more unhandled exceptions than I want.

Is it safe to suppress any TaskCanceledException, no matter what CancellationToken it contains? Where does this mystery CancellationToken come from, and could ExecuteReaderAsync just return the CancellationToken given to it?

                using (var cts = new CancellationTokenSource())
                {
                    using (var cmd = db.GetSqlStringCommand(queryString))
                    {
                        cts.Cancel();
                        try
                        {
                            using (var rdr = cmd.ExecuteReaderAsync(cts.Token).Result)
                            {
                            }
                        }
                        catch (Exception ex3)
                        {
//  if you inspect ex3, you will find a TaskCanceledException buried in InnerExceptions, but its CancellationToken is not cts.Token
                            throw;
                        }
                    }
                }

Author:	Coder3333
Assignees:	-
Labels:	area-System.Threading.Tasks, untriaged
Milestone:	-

[campersau]

Looks like this code is always creating a new cancelled CancellationToken but it could just use the one which is passed in in the calling method. Also looks like this helper isn't really needed since it could be inlined?!

https://github.com/dotnet/runtime/blob/6714f8175ff32daa501c7061a3237fafcead88c9/src/libraries/System.Data.Common/src/System/Data/Common/AdapterUtil.Common.cs#L22

Tagging subscribers to this area: @roji, @ajcvickers
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I am witnessing this behavior in packages\netstandard.library\2.0.3\build\netstandard2.0\ref\netstandard.dll when running from a .Net Core 3.1 application.

When I call DbCommand.ExecuteReaderAsync with a CancellationToken and cancel it before it finishes, an exception is thrown that contains a TaskCanceledException buried down in the InnerExceptions. I expect that behavior, but the issue is that the TaskCanceledException.CancellationToken is not the CancellationToken that I provided to ExecuteReaderAsync. I do not know where this other CancellationToken is coming from, but I thought we were only supposed to suppress TaskCanceledException in our applications if it is for the provided CancellationToken, so I end up with a lot more unhandled exceptions than I want.

Is it safe to suppress any TaskCanceledException, no matter what CancellationToken it contains? Where does this mystery CancellationToken come from, and could ExecuteReaderAsync just return the CancellationToken given to it?

                using (var cts = new CancellationTokenSource())
                {
                    using (var cmd = db.GetSqlStringCommand(queryString))
                    {
                        cts.Cancel();
                        try
                        {
                            using (var rdr = cmd.ExecuteReaderAsync(cts.Token).Result)
                            {
                            }
                        }
                        catch (Exception ex3)
                        {
//  if you inspect ex3, you will find a TaskCanceledException buried in InnerExceptions, but its CancellationToken is not cts.Token
                            throw;
                        }
                    }
                }

Author:	Coder3333
Assignees:	-
Labels:	area-System.Data, untriaged
Milestone:	-

[roji]

@Code3333 I'm assuming you are using System.Data.SqlClient or Microsoft.Data.SqlClient, can you please confirm (and say which one)?

When I call DbCommand.ExecuteReaderAsync with a CancellationToken and cancel it before it finishes, an exception is thrown that contains a TaskCanceledException buried down in the InnerExceptions. I expect that behavior [...]

This is actually a problem - async APIs are expected to raise a TaskCanceledException directly when cancellation occurs, without wrapping it; this is important to get the proper Status in the resulting Task (i.e. Canceled rather than Faulted). Assuming you're on SqlClient, this is tracked by #26.

[...] the issue is that the TaskCanceledException.CancellationToken is not the CancellationToken that I provided to ExecuteReaderAsync

That also sounds like a bug - pending confirmation that you're on SqlClient I'll transfer this over to that repo.

[Coder3333]

@roji I updated my original issue. This happens with both versions of SqlClient and the exception is wrapped in an AggregateException, instead of throwing a TaskCanceledException directly.

@Code3333 I'm assuming you are using System.Data.SqlClient or Microsoft.Data.SqlClient, can you please confirm (and say which one)?
This is actually a problem - async APIs are expected to raise a TaskCanceledException directly when cancellation occurs, without wrapping it; this is important to get the proper Status in the resulting Task (i.e. Canceled rather than Faulted). Assuming you're on SqlClient, this is tracked by dotnet/SqlClient#26.

[roji]

Transferred this to the SqlClient repo.

Specifically for AggregateException being thrown, see #1213 where this was fixed in at least some places for 4.0.0-preview.1 - maybe check that version out. If you're still seeing AggregateException being thrown, I'd recommend opening another issue on this repo with the repro, and leaving this issue to track the incorrect cancellation token.

[JRahnama]

@roji thanks for transferring this. @Coder3333 I will look into it and update you shortly.