Inconsistent ResponseStatus and ErrorMessage in case of timeout

[snechaev]

Describe the bug
When the request is timed out, RepsonseStatus becomes TimedOut, but ErrorMessage becomes “A task was canceled”, which is a bit contradictory.

To Reproduce
Code

using RestSharp;
using var client = new RestClient("http://google.com");
var request = new RestRequest("index.html"){Timeout = TimeSpan.FromMilliseconds(1)};
var response = await client.ExecuteAsync(request);
Console.WriteLine(response.ResponseStatus);
Console.WriteLine(response.ErrorMessage);

• Run the code above
• If needed, use Fiddler or any other tool/method to force the request to time out.
• Observe the status and error message in the console. It should be

TimedOut //<--ResponseStatus
A task was canceled. //<--ErrorMessage

Expected behavior
The ErrorMessage should tell us about the timeout I guess, to be consistent with the status and real situation (no cancellation was requested from user). For example, in the RestSharp 106 the message was "The operation has timed out." or "The request timed-out." depending on where the timeout was set (on the RestClient or RestResponse, respectively). As an alternative the full error message from the inner HttpClient may be used. It looks like this: "The request was canceled due to the configured HttpClient.Timeout of 0,001 seconds elapsing." and also describes the situation in non-confusing way.

Stack trace
No exception.

Desktop (please complete the following information):

• OS: macOS 14.6.1 & Win11
• .NET version net8
• Version 111.4.1

Additional context
none

[alexeyzimarev]

There's no exception from HttpClient being produced in case of time outs because RestSharp uses a cancellation token source with a given delay to control the maximum request duration. HttpClient timeout exception is only produced when an external HttpClient instance is used instead of the default one created by RestClient.

The ErrorMessage property is set to the exception message, and in this case it's the TaskCancelledException. I am not sure what's more confusing - a timeout status with message "task cancelled" or an error message that doesn't match with the exception.

[snechaev]

Hm... Let's make sure that I fully understand your point.
The RestReposnse has the following properties related to its state:

• ErrorException
• ErrorMessage
• RepsonseStatus

The first two are connected directly as ErrorMessage = ErrorException.Message, and the last one is the result of a some kind of heuristic, based on Exception and CancallationTokenSource, among others.

Ideally we want that all 3 of these properties to be in sync and also describe the state as more accurately as possible.

For now, in the case of the timeout, we have

• RepsonseStatus explains the situation perfectly, but is out of sync with two others
• ErrorMessage & ErrorException are in sync between each other, but tell us about the cancellation, not about the timeout.

And if we will fix only the ErrorMessage we will get the situation where the RepsonseStatus and ErrorMessage are in sync with each other, but out of sync with the ErrorException. And this is exactly the same inconsistency as the initial one, but for other properties.

Is it correct?

---

I also checked the implementation of the HttpClient and found the following:

• they also use the CancellationTokenSource to handle the timeouts: https://github.com/dotnet/runtime/blob/dd01b550df949fc06bc771f54cbf51c7b76c75fc/src/libraries/System.Net.Http/src/System/Net/Http/HttpClient.cs#L808
• in case of timeout they just wrap the initial OperationCancelledException in the new one with a custom message (which is about timeout, not about the cancellation): https://github.com/dotnet/runtime/blob/c87cbf63954f179785bb038c23352e60d3c0a933/src/libraries/System.Net.Http/src/System/Net/Http/HttpClient.cs#L605 (and also adds intermediate TimeoutException as the inner one).

Maybe RestSharp can implement something similar with a exception wrapping? In this case we will have:

• The type of the ErrorException will not change (but the internal hierarchy of the InnerExceptions will).
• The new custom message of the outermost exception will tell us about the timeout, which is correct.
• All 3 mentioned properties will be synchronized both technically and by the meaning.

I'm not familiar with RestSharp internals and public API contracts, so I can't say for sure about the possible side effects of such a fix. It might be that the game is not worth the candle.

[alexeyzimarev]

Yeah, I actually agree that it makes sense, I just worry that there's some existing code out there that relies on the current behaviour. I'd like to keep the issue open, and consider it for the next major version.