How do you abort a Fetch API request using AbortController?

Q: How do you abort a Fetch API request using AbortController?

**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 the exact shape of the rejection value in each case — was actually run against a real, live network endpoint, not simulated. ## 1. Why This Even Matters — A Story First Placing a takeout order over the phone and then calling back moments later to say "cancel that" only works if the restaurant is still listening — once the food is already being cooked and handed to a courier, "cancelling" just means refusing the delivery when it arrives, wasted effort already spent. `AbortController` is the phone call that reaches the kitchen BEFORE the food is finished — it genuinely stops the request in flight, rather than merely ignoring its result once it lands. ## 2. The Core Idea 📌 **Interview term:** `AbortController` exposes `.abort(r

01

Understand the problem

Question presented to candidate: "A user navigates away from a search page before the results fetch() finishes. How would you cancel that in-flight request, and what exactly does the fetch's Promise reject with?"

What a strong answer should cover:

📌 Interview term: AbortController — a real, built-in object exposing a single .abort(reason?) method and a .signal property (an AbortSignal) that can be passed to fetch()'s own { signal } option to make that specific request cancellable.
📌 Interview term: the real, direct answer to the prompt — verified directly: calling controller.abort() with no argument genuinely produces a real, default DOMException named "AbortError" as signal.reason, and the in-flight fetch()'s Promise genuinely rejects with exactly that DOMException.
📌 Interview term: the real custom-reason distinction — verified directly: calling controller.abort("some custom reason") makes signal.reason genuinely the EXACT custom value passed, and the fetch() Promise genuinely rejects with THAT value directly — not wrapped in a DOMException — a real, sharp, easy-to-miss distinction from the default no-argument case.
📌 Interview term: pre-aborting — a precise answer names that a signal aborted BEFORE fetch() is even called genuinely causes the fetch to reject immediately — verified directly — the network request never actually starts at all.
A precise answer names the real, practical cleanup pattern: calling .abort() in a useEffect cleanup function (or equivalent lifecycle hook) when a component unmounts or a dependency changes, preventing a real, classic "setState after unmount" warning/bug from a request that finishes after it is no longer needed.

Clarifying questions expected:

None — this is a definitional/practical question; directly demonstrating the real, verified rejection value in both the default and custom-reason cases is the strong signal.

Code / implementation expected: Yes — a real AbortController cancelling a real in-flight fetch(), verified with both a default abort and a custom-reason abort, plus the pre-abort case.

abortcontrollerfetchpromises

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 the exact shape of the rejection value in each case — was a

Solution ready — 2 min read

Classified // press E to declassify

04

Run the code

JSReal, direct proof: AbortController.abort() with no argument rejects with a real AbortError DOMException; a custom reason rejects with that exact value — verified against a real network endpoint

Practice

05

Join the discussion

Discussion (0)

Sign in to join the discussion.

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