fetch + AbortController: Cancel Ghost Requests

Every fetch request you start should have a cancellation strategy. The two common triggers: (1) the component unmounted before the response arrived, or (2) a new request superseded the old one. Without cancellation, both result in stale-data updates, wasted bandwidth, and potential state corruption.

// Complete fetch wrapper with cancellation
async function fetchWithAbort(url, signal) {
  try {
    const res = await fetch(url, { signal });
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    return await res.json();
  } catch (err) {
    if (err.name === 'AbortError') return null; // cancelled — not an error
    throw err; // real error — re-throw
  }
}

// Usage: cancel previous, start new
let currentController = null;
async function loadData(id) {
  currentController?.abort();
  currentController = new AbortController();
  const data = await fetchWithAbort(`/api/${id}`, currentController.signal);
  if (data) updateUI(data); // data is null if aborted
}

What happened technically: each keystroke fired a fetch with no cancellation of the previous request. The network isn't orderly — the response for "react" (a shorter, more cached query) arrived 200ms after the response for "react hooks." JavaScript ran the state update for "react" last, overwriting the "react hooks" results. This is a race condition: two async operations competing to write the same state, where "last to resolve" wins regardless of which request was sent most recently.

The team replaced the raw fetch with a controlled pattern:

// Module-level controller reference
let searchController = null;

async function search(query) {
  // Cancel the previous request if still in flight
  searchController?.abort();
  searchController = new AbortController();

  try {
    const res = await fetch(`/api/search?q=${query}`, {
      signal: searchController.signal,
    });
    const data = await res.json();
    renderResults(data); // only reaches here if not aborted
  } catch (err) {
    if (err.name === 'AbortError') return; // expected — ignore
    showError(err); // real network error
  }
}

The race condition was eliminated. Results now always match the most recent query. Open the Network panel — aborted requests show as "cancelled" with a strikethrough, confirming the connection was truly dropped.

Open the Network panel. "Fixed" shows the request as "cancelled" with a strikethrough — the connection was actually dropped, not just ignored.

React useEffect cleanup is the canonical place to call abort():

function SearchResults({ query }) {
  const [results, setResults] = React.useState([]);

  React.useEffect(() => {
    const controller = new AbortController();

    async function fetchResults() {
      try {
        const res = await fetch(`/api/search?q=${query}`, {
          signal: controller.signal,
        });
        if (!res.ok) throw new Error(`HTTP ${res.status}`);
        setResults(await res.json());
      } catch (err) {
        if (err.name !== 'AbortError') console.error(err);
      }
    }

    fetchResults();

    // Cleanup: runs on next render (new query) AND on unmount
    return () => controller.abort();
  }, [query]); // re-runs when query changes

  return <ul>{results.map(r => <li key={r.id}>{r.title}</li>)}</ul>;
}

Implementation notes:

• Debounce vs abort: debounce reduces how often fetch fires (fewer requests); abort ensures stale requests can't corrupt state (data integrity). Use both
• AbortSignal.timeout(ms): creates a signal that auto-aborts after N ms — no controller needed for simple fetch timeouts
• One signal, many fetches: pass the same signal to multiple fetch() calls in a Promise.all — one abort() cancels all of them
• TanStack Query: passes AbortSignal to query functions automatically in v5 — thread it to fetch() inside your query function