Cancelling a Request Nobody Is Waiting For

1function useOrders(filter: string) {
2  const [state, setState] = useState<State>({ status: 'idle' })
3 
4  useEffect(() => {
5    // A fresh controller per effect run. Controllers are one-shot.
6    const lifetime = new AbortController()
7    const signal = AbortSignal.any([lifetime.signal, AbortSignal.timeout(DEADLINE)])
8 
9    setState({ status: 'pending' })
10 
11    ;(async () => {
12      try {
13        const res = await fetch(`/api/orders?filter=${encodeURIComponent(filter)}`, { signal })
14        if (!res.ok) { setState({ status: 'error', error: classify(res) }); return }
15        setState({ status: 'success', data: await res.json() })
16      } catch (e) {
17        // The one check this whole lesson exists for.
18        if (e instanceof DOMException && e.name === 'AbortError') return   // silence
19        setState({ status: 'error', error: { kind: 'network' } })
20      }
21    })()
22 
23    // Unmount, or `filter` changed: this answer is no longer wanted.
24    return () => lifetime.abort()
25  }, [filter])
26 
27  return state
28}

Two subtleties. AbortSignal.any means the deadline also stops the body read, not just the headers. And the cleanup aborts on *every* change of filter, so a fast typist never has more than one search request outstanding — the cancellation is doing the work people usually try to get from a debounce alone.

• Type "re" → request A — Slow: a cold path on the server, or a large result set.
• Type "refu" → request C — The only answer the user actually wants.
• Parse + render C — Correct results on screen.
• Parse + render A (uncancelled) — The stale answer lands last and wins. The user searched "refu" and is looking at results for "re".
• Abort A and B at keystroke — With cancellation: A and B never reach parse, and the connections are freed for C.
• Main thread free for input — The saving is not bandwidth. It is the parse and render work that never runs on the thread the user is typing on (Long Tasks).

Two separate wins, often confused: cancellation frees connections and main-thread work; generation stamping is what guarantees correctness. Ship both.

1. 1
   1. Create a controller per request

   Establishes a signal whose lifetime matches the interest in the answer.

   fails by Reusing a controller across requests — the second request is aborted before it starts.

2. 2
   2. Attach the signal to `fetch`

   Lets the browser stop the transfer and the body read on demand.

   fails by Passing the controller instead of controller.signal, which silently does nothing.

3. 3
   3. Combine with a deadline

   Adds a second, independent reason to stop, via AbortSignal.any.

   fails by Having only a deadline, so a route change leaves the request running.

4. 4
   4. Abort from teardown

   Unmount, route change, or the next supersedig query flips the signal.

   fails by A teardown that never runs, or one that runs on every render and cancels the request it just started.

5. 5
   5. The browser stops the work

   Connection released; transfer, decompression and parse abandoned.

   fails by Nothing — but note the server may already have finished, and a mutation may already have applied.

6. 6
   6. The promise rejects with `AbortError`

   Gives you a discriminable, deliberate outcome.

   fails by A catch-all handler that reports it as a network failure. This is the defining bug of the lesson.

7. 7
   7. Clear the busy state

   Returns the region to a state where later updates are announced and rendered.

   fails by Leaving aria-busy="true" or a pending flag set, so the UI is silent and spinning forever (Live Regions and Announcement).

Steps 5 and 6 are where the mental model has to bend: the work stops on the client, the rejection is not a failure, and neither fact says anything about what the server did.