HttpClient Timeout Bug In .NET 10? Triage Report

Hey guys, let's dive into this interesting issue! We're looking at a potential bug where the HttpClient's timeout isn't working as expected when using HttpContent in .NET 10. Specifically, when you set a timeout and use HttpClient.GetAsync with content, the code should throw a TaskCanceledException after the timeout. However, it looks like in this case, it's just returning a response after the delay, which isn't the intended behavior. This report is all about trying to figure out what's going on and if it's a regression – meaning a previously fixed issue has resurfaced. Let's dig in and see what we can find!

Understanding the Problem: HttpClient Timeout and Task Cancellation

The Core Issue: Timeout Not Triggering Exception

The central problem, folks, is that the HttpClient's timeout isn't properly triggering a TaskCanceledException when it should. When you set a timeout, .NET is supposed to cancel the ongoing request if it exceeds that time. For instance, if you've set a timeout of, say, 5 seconds and your server takes longer than that to respond, the HttpClient should throw a TaskCanceledException. The current behaviour of .NET 10 appears to return a delayed response instead of throwing the expected exception after the timeout period, which is definitely not cool.

Why This Matters: Consistent Behavior

Consistent behavior in your code is super important. When you rely on timeouts to handle potential issues (like a slow server or a network glitch), you need to know they're going to behave predictably. If the timeout mechanism fails, it can lead to all sorts of problems – from your app hanging to the user waiting forever. In essence, the HttpClient's timeout is essential for making your applications robust and reliable when dealing with network requests. A change like this can also be quite frustrating for developers because this could introduce subtle bugs that can be difficult to track down. This can impact the users and developers in a big way.

Keywords to Focus On:

• HttpClient
• Timeout
• TaskCanceledException
• HttpContent
• .NET 10
• Regression

Related Issues and Discussions: What the Tools Found

Okay, so the bot has been working hard to look for similar issues. Let's see what it has found.

1. Issue #21965: HttpClient throws TaskCanceledException on timeout

This one, dating back to May 2017, focuses on the general design surrounding HttpClient and how it handles timeouts. The main discussion is about the confusion around HttpClient throwing TaskCanceledException. The cool thing is that the team actually considered different options like introducing a new exception type or even wrapping a TimeoutException. The solution, starting with .NET 5, was to throw a TaskCanceledException with an inner TimeoutException to enable programmatic distinction between the two. However, the report indicates it doesn't address the specific regression where the response is returned instead of the exception. This old issue provides valuable context about the expected behaviour of TaskCanceledException during timeouts and the importance of a consistent exception-handling system.

2. Issue #28063: HttpClient Timeout incorrectly implemented

This issue, from December 2018, questions whether HttpClient.Timeout should behave more like an idle timeout. Right now, it cancels the request when the entire timeout period is exceeded. While it's not directly about our current regression, it gives us an understanding of how the Timeout property is intended to work. It highlights that the Timeout is supposed to cover the whole request, even content reading. This is important to understand when we are troubleshooting our current issue because the Timeout should apply to the content as well.

3. Issue #28952: HttpClient timeout handling

From March 2019, this issue touches on the need for more granular timeout controls and the limitations of the current Timeout property. It again reinforces that the timeout should include everything, which is what we expect. This makes it a relevant piece of background information because the expectation is that the timeout should handle the content reading. So we know what the expected behaviour should be.

4. Issue #103134: HttpClient.Timeout seems to be canceling before expected

This one is from June 2024. This one is pretty recent! This one isn't the same regression but it's discussing an issue where the timeout is firing before the expected time. It's related to DNS or connection issues. While it shows recent investigation into timeout behavior, but it's not the same issue as the one we are investigating.

5. Issue #36822: HttpClient Response Stream hangs and doesn't respect timeout (only HttpCompletionOption.ResponseHeadersRead)

This issue from May 2020, where the response stream can hang and not respect the timeout, is more similar to our current problem, but it's a different scenario. In this issue, the timeout is not respected when reading content but our case is the timeout not being enforced at all when content is present. This is similar to our case but focuses on a specific condition, which helps in the troubleshooting, but the current problem is more general.

6. Issue #17332: HttpClient ignores Timeout and cancellation token for slow response body reads on Windows

This one from May 2016 is a direct precedent for the type of bug we are reporting. It is reporting that HttpClient.Timeout and the cancellation tokens were not respected during slow reads. It was considered fixed in the recent .NET versions. This is a direct parallel to the kind of bug we are discussing – a regression in enforcing the timeout during content reading, making this a very important issue to note!

7. Issue #67537: [NativeAOT] Httpclient timeout

This one, reported in April 2022, is about HttpClient.Timeout not being respected. But it's about ConnectTimeout and NativeAOT and not about general content reading, which makes it less relevant to the current problem.

8. Issue #82878: .NET 7 breaking change in HttpClient timeout handling

From March 2023, this reports a breaking change in .NET 7, where custom handlers throwing OperationCanceledException aren't wrapped to include a TimeoutException. This isn't directly related to our core issue but is relevant as it shows recent modifications in timeout and cancellation handling.

9. Issue #88074: [Dotnet 6.0] Timeout error always says "The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing", even when timeout is different from 100sec

This one from June 2023 reports incorrect error messages for timeouts, but it's not about the timeout not being enforced. It's not the same regression as we are looking at.

10. Issue #79443: HttpClient becomes very slow and cancel request after migrating to NET 7

This one talks about requests being cancelled after the timeout. However, it is not stating that the timeout is being ignored, making it not relevant to our case.

Summary of Findings

Here's what we've gathered, folks:

• There's a history of confusion and bugs with HttpClient.Timeout, including when and how it is enforced and which exceptions are thrown.
• Older issues (like #17332 and #36822) indicate that timeouts weren't always respected during content reading, but these were supposedly fixed in recent versions.
• Our reported regression, where the timeout is not enforced when content is present, looks to be a new issue or a re-emergence of a previously fixed one.
• No existing issue or comment describes the exact issue we're seeing in .NET 10.

Recommendations

Alright, here's what we should do to tackle this:

• Reference issues #17332 and #36822 for historical context.
• Reference issue #21965 for the design details around timeout exceptions.
• Clearly state in the triage report that this appears to be a regression in .NET 10, as the behavior is correct in .NET 8 and 9, and there are no open issues describing this exact problem.
• Suggest labeling as a regression and breaking change for the area-System.Net.Http team.

Let me know if you need more info on any of these issues or want to see the full comment history!