Use descriptive ErrorMessage for timed out requests

[alexeyzimarev]

Summary

• When a request times out, ErrorMessage now says "The request timed out." instead of "A task was canceled."
• ErrorException still holds the original TaskCanceledException unchanged
• All three state properties are now consistent: ResponseStatus.TimedOut + meaningful ErrorMessage + original ErrorException
• Non-timeout errors (aborted, network errors, etc.) are unaffected

Fixes #2257

Test plan

• Project builds successfully
• All existing unit tests pass
• No existing tests assert on ErrorMessage string content for timeout cases

🤖 Generated with Claude Code

[qodo-free-for-open-source-projects]

Review Summary by Qodo

Use descriptive ErrorMessage for timed out requests

🐞 Bug fix

Walkthroughs

Description

• Fixes inconsistent ErrorMessage for timed out requests
• Sets ErrorMessage to "The request timed out." when timeout occurs
• Maintains consistency between ResponseStatus.TimedOut and error message
• Preserves original TaskCanceledException in ErrorException

Diagram

flowchart LR
  A["Request times out"] -->|OperationCanceledException| B["Check if TimedOut"]
  B -->|Yes| C["ResponseStatus.TimedOut"]
  B -->|Yes| D["ErrorMessage: 'The request timed out.'"]
  B -->|No| E["ResponseStatus.Aborted"]
  B -->|No| F["ErrorMessage: exception message"]
  C --> G["Consistent state"]
  D --> G

Loading

File Changes

1. src/RestSharp/RestClient.Async.cs 🐞 Bug fix +4/-2

Set descriptive error message for timeout scenarios

• Extracts timeout check into timedOut variable to avoid duplicate evaluation
• Sets ErrorMessage to "The request timed out." when timeout occurs
• Uses timedOut flag for both ResponseStatus and ErrorMessage assignment
• Preserves original exception message for non-timeout cancellation scenarios

src/RestSharp/RestClient.Async.cs

---

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (1) 📎 Requirement gaps (0)

1. timedOut boolean lacks prefix 📘 Rule violation ✓ Correctness

Description

The new boolean local timedOut does not use the recommended boolean naming prefix (e.g.,
isTimedOut). This reduces self-documentation consistency and readability for boolean state
variables.

Code

src/RestSharp/RestClient.Async.cs[64]

+        var timedOut = exception is OperationCanceledException && TimedOut();

Evidence

PR Compliance ID 2 requires boolean variables to use prefixes like is_/has_ for self-documenting
code; the PR introduces a boolean named timedOut without such a prefix.

Rule 2: Generic: Meaningful Naming and Self-Documenting Code
src/RestSharp/RestClient.Async.cs[64-70]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A new boolean local variable is named `timedOut` without a boolean prefix, which conflicts with the naming guidance for self-documenting code.

## Issue Context
The code introduces a timeout flag used to set `ResponseStatus` and `ErrorMessage`. Renaming to `isTimedOut` (or similar) improves readability and aligns with the boolean naming convention.

## Fix Focus Areas
- src/RestSharp/RestClient.Async.cs[64-70]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Inconsistent timeout messages 🐞 Bug ✧ Quality

Description

For the same timeout condition, RestResponse.ErrorMessage now differs from the exception message
thrown by ThrowIfError() ("The request timed out." vs "Request timed out"), which can confuse
consumers and complicate logging/error handling.

Code

src/RestSharp/RestClient.Async.cs[70]

+            ErrorMessage   = timedOut ? "The request timed out." : exception.GetBaseException().Message,

Evidence

The PR hard-codes a new timeout-specific ErrorMessage, while ThrowIfError() relies on
RestResponseBase.GetException() which constructs a TimeoutException with different text. This
creates two different user-facing messages for the same timeout scenario depending on which API
surface is used.

src/RestSharp/RestClient.Async.cs[63-77]
src/RestSharp/Response/RestResponseBase.cs[152-160]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Timeouts now produce two different user-facing messages:
- `RestResponse.ErrorMessage`: "The request timed out."
- `ThrowIfError()` thrown `TimeoutException.Message`: "Request timed out"
This inconsistency can confuse consumers who compare/log both.

### Issue Context
`ThrowIfError()` uses `RestResponseBase.GetException()` which currently hard-codes the `TimeoutException` message.

### Fix Focus Areas
- src/RestSharp/RestClient.Async.cs[63-77]
- src/RestSharp/Response/RestResponseBase.cs[152-160]

### Suggested approach
- Prefer a single shared message for timeouts.
 - Option A: Change `GetException()` to use `ErrorMessage` when available, e.g. `new TimeoutException(ErrorMessage ?? "Request timed out", ErrorException)`.
 - Option B: Introduce a shared internal constant (e.g., `TimeoutErrorMessage`) and use it in both places.
- Consider also aligning punctuation/casing to avoid subtle diffs.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Missing timeout ErrorMessage test 🐞 Bug ⛯ Reliability

Description

The new timeout-specific ErrorMessage behavior isn’t asserted by tests; existing timeout tests
validate ResponseStatus but not the ErrorMessage value, reducing confidence in the intended
contract.

Code

src/RestSharp/RestClient.Async.cs[70]

+            ErrorMessage   = timedOut ? "The request timed out." : exception.GetBaseException().Message,

Evidence

The PR introduces a new constant ErrorMessage for timeouts, but the existing timeout tests don’t
assert the message value (only ResponseStatus and ErrorException type). Adding assertions will lock
in the intended behavior.

src/RestSharp/RestClient.Async.cs[63-77]
test/RestSharp.Tests.Integrated/NonProtocolExceptionHandlingTests.cs[19-53]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Timeout tests cover `ResponseStatus.TimedOut` but do not assert the newly introduced `ErrorMessage` value. This leaves the new behavior unprotected.

### Issue Context
Timeout message is now set to a constant string ("The request timed out.") in `GetErrorResponse`.

### Fix Focus Areas
- test/RestSharp.Tests.Integrated/NonProtocolExceptionHandlingTests.cs[19-53]
- src/RestSharp/RestClient.Async.cs[63-77]

### Suggested approach
- In `Handles_HttpClient_Timeout_Error`, assert:
 - `response.ErrorMessage.Should().Be("The request timed out.");`
- In `Handles_Server_Timeout_Error` and `Handles_Server_Timeout_Error_With_Deserializer`, also assert the same.
- If message is intended to be stable API, keep exact-string assertion; otherwise consider asserting it is non-empty and contains "timed out".

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more

[cloudflare-workers-and-pages]

Deploying restsharp with    Cloudflare Pages

Latest commit:	7fb5c19
Status:	✅  Deploy successful!
Preview URL:	https://ce3b299c.restsharp.pages.dev
Branch Preview URL:	https://fix-timeout-error-message.restsharp.pages.dev

View logs

[sonarqubecloud]

Quality Gate failed

Failed conditions
B Maintainability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE