Using fetch with timeouts and AbortController

Goal

Every fetch call is bounded in time, can be cancelled when its result is no longer wanted, and reports HTTP failures as errors instead of treating a 500 as success.

Prerequisites

Three documented facts. A fetch() promise rejects only when the request itself fails (malformed URL, network error); it does not reject on HTTP error statuses, so response.ok or response.status must be checked. An AbortController supplies a signal; calling abort() rejects the pending fetch with an AbortError. AbortSignal.timeout(ms) returns a signal that aborts with a TimeoutError after the given active time, and AbortSignal.any([...]) combines several signals.

Steps

1. Write one request helper used everywhere. It takes URL, options and a timeout, and builds the signal: AbortSignal.any([options.signal, AbortSignal.timeout(ms)].filter(Boolean)).
2. After the promise resolves, check response.ok. On failure read a bounded slice of the body for diagnostics and throw an error carrying method, URL and status.
3. In the catch, branch on the failure kind: err.name === "TimeoutError" (a retry may be reasonable), err.name === "AbortError" (the caller cancelled; not a failure to report), a TypeError (network, DNS or CORS problem; report it), or the HTTP error from step 2 (retry only idempotent requests with retryable statuses).
4. For requests that supersede each other, such as search-as-you-type or route changes, keep one controller per slot: abort the previous request before starting the next and ignore the resulting AbortError.
5. Keep the signal in force while reading the body (await response.json()), which is part of the same fetch; do not start a separate timer for it.
6. Remove listeners you added to long-lived signals when done; a pending timeout signal with listeners is kept alive until it fires.
7. Test the three paths with a stub server: never responds (timeout), responds 500 (HTTP error), cancelled mid-flight (abort).

Expected result

No request can hang indefinitely, cancelled requests produce no error reports, and every HTTP failure surfaces with status and URL attached.

Limits and test basis

The timeout counts active time only; it pauses while a worker is suspended or a page sits in the back-forward cache. Aborting does not undo a request the server has already processed, so writes still need idempotency keys. Behaviour follows the cited MDN pages; no timings are claimed.

Retrying after a timeout

A timeout usually means the server is slow or overloaded, so retries add load exactly when it hurts most. Retry a timed-out request only when it is idempotent (GET, PUT, DELETE, or a POST carrying an idempotency key), at most once or twice, with jittered backoff, and stop after consecutive timeouts rather than continuing. A server may have completed the request before the client gave up, so a retried write without an idempotency key can execute twice. Treat a TimeoutError on a non-idempotent request as a failure to report, not as an invitation to retry, and prefer the server's own Retry-After when a 429 or 503 provides one.