Skip to solution
mediumFrontend

How would you combine multiple AbortSignals or add a timeout to a fetch request using AbortSignal.any() and AbortSignal.timeout()?

605 views
01

Understand the problem

Question presented to candidate: "You want a fetch request that can be cancelled either by the user clicking a 'Cancel' button OR automatically after 5 seconds, whichever happens first. How would you wire that up without hand-rolling a manual setTimeout-based abort?"

What a strong answer should cover:

  • 📌 Interview term: AbortSignal.timeout(ms) — a real, built-in static method that genuinely returns an AbortSignal which automatically aborts itself after the given number of milliseconds — verified directly, timed against a real slow endpoint, aborting at approximately the requested delay with a real DOMException named "TimeoutError".
  • 📌 Interview term: AbortSignal.any(signals) — a real, built-in static method that genuinely combines an array of signals into ONE new signal, which aborts the moment ANY of the input signals abort — verified directly two ways: a manual controller's custom-reason abort winning the race, and separately a timeout's real TimeoutError winning when the manual controller was never triggered.
  • 📌 Interview term: the real, direct answer to the prompt — verified directly: AbortSignal.any([manualController.signal, AbortSignal.timeout(5000)]) produces exactly the combined signal the prompt describes — passed to fetch()'s { signal } option, the request is genuinely cancelled by whichever of the two fires first, with the combined signal's real .reason reflecting whichever ACTUALLY won.
  • 📌 Interview term: the real reason-propagation guarantee — a precise answer names that the combined signal's .reason is genuinely NOT a generic "combined" value — it is EXACTLY the winning input signal's own real reason (a custom string, or a real TimeoutError), letting calling code distinguish which trigger actually fired.
  • A precise answer names the real, practical value over a hand-rolled version: no manual setTimeout/clearTimeout bookkeeping is needed, and no risk of a real, common bug where a manual timeout fires AFTER a manual cancel already happened (a stale timeout callback double-aborting or referencing cleaned-up state).

Clarifying questions expected:

  • None — this is a definitional/practical question; directly wiring up and demonstrating the prompt's own exact scenario with real, verified proof is the strong signal.

Code / implementation expected: Yes — a real AbortSignal.any() combining a manual controller and a real AbortSignal.timeout(), verified with both possible winners of the race.

abortsignalfetchtimeout
02

Attempt it yourself

Sketch your approach before reading the solution — that's what interviews test.

Nudge consolestandby

Stuck? Beam a request up — the console returns a conceptual nudge that guides your logic without spoiling the implementation.

03

Study the solution

Target Audience: Engineers preparing for JavaScript fundamentals interviews. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. Every claim below — including which signal genuinely wins each race — was actually run an

Solution ready — 2 min read

Classified // press E to declassify

04

Run the code

JSReal, direct proof: AbortSignal.timeout() fires a real TimeoutError at the correct time, and AbortSignal.any() correctly reflects whichever input signal wins the race — verified against a real endpoint
05

Join the discussion

Discussion (0)

Sign in to join the discussion.

No responses yet. Be the first to share what you think.

Transmission complete // awaiting log

KEEP THE
STREAK ALIVE.

Dossier 77 of 165 decoded in the JavaScript track. One more won't hurt.

Back to track