AbortSignal.timeout yields TimeoutError while retry policies expect AbortError classification

Answer

Treat a TimeoutError from AbortSignal.timeout() as retryable unless your policy explicitly marks deadline expiry as permanent. Distinguish it from caller‑initiated AbortError by inspecting the error’s name property (or instanceof DOMException check) and map both to an internal error type before feeding them to retry logic. Normalizing the TimeoutError to AbortError is only needed when the existing retry infrastructure cannot be changed; otherwise it hides the semantic difference and may cause unwanted retries of user cancellations.

Likely explanation

The DOM specification deliberately uses two distinct DOMException subclasses: TimeoutError for deadline expiry and AbortError for explicit aborts. Retry policies that treat any abort‑derived rejection as non‑retryable therefore misclassify timeouts as permanent failures, even though a timeout is typically a transient condition that benefits from retry.

Confirmed facts

• AbortSignal.timeout(ms) rejects with a DOMException whose name is "TimeoutError".
• AbortController.abort() rejects with a DOMException whose name is "AbortError".
• The name property is stable across browsers that implement the API; it is not a message string that can change.

Steps for this case

1. When catching errors from fetch or custom async work, test the caught value:

if (err instanceof DOMException) {
    if (err.name === 'TimeoutError') {
      // deadline expiry → treat as retryable
    } else if (err.name === 'AbortError') {
      // caller‑initiated abort → treat as non‑retryable (unless policy says otherwise)
    }
  }
  

2. If you prefer not to expose DOMException details higher up, map each case to an internal error object, e.g.:

function classifyAbortError(err) {
    if (!(err instanceof DOMException)) return null;
    if (err.name === 'TimeoutError') return { type: 'timeout', retryable: true };
    if (err.name === 'AbortError')   return { type: 'cancel',  retryable: false };
    return null;
  }
  

3. Feed the retryable flag (or the internal type) to your retry wrapper; do not rely on string matching of err.message.
4. Only consider normalizing TimeoutError to AbortError in custom wrappers if the surrounding retry system cannot be changed and you are certain that retrying caller‑initiated cancellations is acceptable for your use case.

Missing diagnostic detail

If your retry policy already distinguishes between transient and permanent failures based on error codes or categories, let me know whether it uses a custom error‑type field; that would change whether you need the internal mapping step.