dotnet/aspnetcore

Misleading TaskCanceledException

Open

#4,747 建立於 2018年5月30日

在 GitHub 查看
 (7 留言) (0 反應) (0 負責人)C# (37,933 star) (10,653 fork)batch import
affected-very-fewarea-networkingbugfeature-kestrelhelp wantedseverity-nice-to-have

描述

I have a WebApi endpoint that parses out the Request.Body itself rather than using Model binding due to performance reasons.

During some requests, I was getting a TaskCanceledException from a TextReader that I never gave any CancellationTokens too. After investigation, I found out that any read operations on the Request.Body after the Request was aborted will throw TaskCanceledExceptions. The stack trace at the time didn't list any Kestrel level code so I spent a lot of time trying to find out how a Stream can possibly cancel a token I never gave it.

This is a bit misleading and should probably change I think.

貢獻者指南

技術棧
csharp
領域
backend
議題類型
bug
難度面向新貢獻者的預計實作難度，1 表示很小改動，5 表示專家級工作。
3
預計時間有經驗貢獻者完成調查、實作、測試並準備 pull request 的粗略時間範圍。
half day
活動狀態議題目前的可參與程度：新鮮、活躍、陳舊、阻塞或等待維護者輸入。
stale
清晰度議題是否清楚說明預期改動、驗收標準和下一步。
mostly clear
前置要求
understand ASP.NET Core request pipelineknow CancellationToken basics
新手友善度1-100 的估計分數，表示該議題對首次貢獻者的友善程度。
30
研究方向
Investigate the source of the TaskCanceledException in the HttpRequest body stream, likely in the Kestrel server implementation. Look at the RequestBodyStream or similar classes in the dotnet/aspnetcore repository. The issue discussion (https://github.com/dotnet/aspnetcore/issues/4747) contains insights. Consider if the exception should be changed to a more specific one like OperationCanceledException, and whether the cancellation token is exposed appropriately.