Avoiding Race Conditions in useEffect with AbortController | Mironsoft

1. Why race conditions in useEffect happen so easily

A race condition in useEffect always arises when an effect performs asynchronous work and its dependencies can change before the first asynchronous operation completes. A classic example is a search field: the user types "re", then "rea", then "react". For every keystroke, useEffect starts a new fetch because the search term changed as a dependency. The three requests run in parallel over the network, and there is no guarantee they return in the order they were started.

Server load, network latency, or a simply slower response path can cause the response to "re" to arrive after the response to "react". Without a safeguard, the stale state update then overwrites the already correct one. The UI briefly, or even permanently, shows the wrong data even though the code looks correct at first glance. This class of bug is tricky precisely because it rarely shows up in local development with fast localhost response times, yet strikes regularly under real network conditions in production.

2. The classic ignore-flag pattern

Before AbortController, the common pattern was a local boolean flag inside the cleanup function. The effect creates an ignore variable, starts the fetch, and checks after the response returns whether ignore has meanwhile been set to true. The cleanup function, which React calls whenever the effect re-runs or the component unmounts, sets exactly this flag. That reliably prevents a stale setState call from going through.

The pattern works, but it has a structural drawback: it only prevents writing the state, not the underlying network request itself. The browser still downloads the response in full, consuming bandwidth and server resources even though the result is ultimately discarded. For small JSON responses this is negligible, but for large payloads, file uploads, or many parallel requests it adds up to noticeable waste. On top of that, the request remains visible as active in the browser DevTools, which needlessly complicates debugging network issues.

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

  useEffect(() => {
    let ignore = false;

    async function fetchResults() {
      const response = await fetch(`/api/search?q=${encodeURIComponent(query)}`);
      const data = await response.json();
      if (!ignore) {
        setResults(data.items);
      }
    }

    fetchResults();

    return () => {
      ignore = true;
    };
  }, [query]);

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

3. AbortController as the native solution

AbortController is a standardized Web API built exactly for this use case: it lets you actively cancel a running asynchronous operation instead of merely ignoring its result. An AbortController object has a signal property that you pass to fetch(). Calling controller.abort() afterwards makes the running fetch throw an AbortError and actually terminates the network connection, instead of waiting for the response and discarding it.

The key advantage over the ignore flag is the symmetry between intent and effect: if a request is no longer relevant, it is actually terminated. That saves bandwidth, reduces server load, and makes the behavior transparently visible in the browser DevTools, since cancelled requests are explicitly marked as cancelled there. For production apps with many concurrent users and frequent typing gestures, that is not a nice-to-have but a measurable difference in server load.

4. Using AbortController correctly inside useEffect

The implementation follows the same cleanup pattern as the ignore flag, but replaces the boolean variable with a real AbortController. The controller is created at the start of the effect, its signal is passed to fetch(), and the cleanup function calls controller.abort(). React automatically runs this cleanup function before the effect runs again or the component unmounts, so every stale request is reliably terminated before a new one starts.

Error handling matters here: a cancelled fetch throws a DOMException of type AbortError. This error should be explicitly filtered out in the catch block, because it is not a real error case but the expected behavior of a deliberately cancelled request. Treating it like a normal network error would incorrectly show an error message in the UI even though the user simply kept typing.

function SearchResults({ query }) {
  const [results, setResults] = useState([]);
  const [error, setError] = useState(null);

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

    async function fetchResults() {
      try {
        const response = await fetch(`/api/search?q=${encodeURIComponent(query)}`, {
          signal: controller.signal,
        });
        if (!response.ok) {
          throw new Error(`HTTP ${response.status}`);
        }
        const data = await response.json();
        setResults(data.items);
        setError(null);
      } catch (err) {
        if (err.name === "AbortError") {
          return; // expected behavior, not a real error
        }
        setError(err.message);
      }
    }

    fetchResults();

    return () => {
      controller.abort();
    };
  }, [query]);

  if (error) return <p role="alert">Error: {error}</p>;
  return (
    <ul>
      {results.map((item) => (
        <li key={item.id}>{item.title}</li>
      ))}
    </ul>
  );
}

5. Building a reusable useAbortableFetch hook

Once multiple components need the same pattern, it is worth extracting a custom hook that encapsulates fetch, AbortController, and error handling. The hook accepts a URL, manages data, loading, and error as internal state, and handles the cancellation logic entirely inside its own useEffect. From the outside, usage stays simple: a component calls useAbortableFetch(url) and gets back an object with the three states, without having to worry about cancellation details.

This encapsulation pays off especially in larger codebases where the same data-fetching pattern shows up in dozens of components. Instead of writing AbortController boilerplate again in every component, you import the hook once and get consistent, race-condition-safe behavior everywhere. Changes to error handling, such as adding retry logic, then only need to be maintained in a single central place.

function useAbortableFetch(url) {
  const [state, setState] = useState({ data: null, loading: true, error: null });

  useEffect(() => {
    const controller = new AbortController();
    setState({ data: null, loading: true, error: null });

    fetch(url, { signal: controller.signal })
      .then((res) => {
        if (!res.ok) throw new Error(`HTTP ${res.status}`);
        return res.json();
      })
      .then((data) => setState({ data, loading: false, error: null }))
      .catch((err) => {
        if (err.name === "AbortError") return;
        setState({ data: null, loading: false, error: err.message });
      });

    return () => controller.abort();
  }, [url]);

  return state;
}

// Usage:
function UserProfile({ userId }) {
  const { data, loading, error } = useAbortableFetch(`/api/users/${userId}`);

  if (loading) return <p>Loading...</p>;
  if (error) return <p role="alert">Error: {error}</p>;
  return <h2>{data.name}</h2>;
}

6. Coordinating multiple parallel requests

Some components trigger several requests at once per effect run, for example when a dashboard widget loads user data, statistics, and notifications simultaneously. A single AbortController can happily be passed to multiple fetch() calls, since the same signal instance can be bound to any number of requests. Calling controller.abort() cancels all attached requests at once, without needing a separate cleanup for each one.

For cases where the requests need to be controllable independently of each other, for example because part of the data is critical and another part is loaded optionally, combining Promise.allSettled() with the shared signal works well. That way a failed or cancelled sub-request stays isolated while the remaining results can still be processed. This prevents a single cancelled request from blocking the entire data-fetching pipeline.

function DashboardWidget({ userId }) {
  const [state, setState] = useState({ user: null, stats: null, notes: null });

  useEffect(() => {
    const controller = new AbortController();
    const opts = { signal: controller.signal };

    Promise.allSettled([
      fetch(`/api/users/${userId}`, opts).then((r) => r.json()),
      fetch(`/api/users/${userId}/stats`, opts).then((r) => r.json()),
      fetch(`/api/users/${userId}/notes`, opts).then((r) => r.json()),
    ]).then(([user, stats, notes]) => {
      setState({
        user: user.status === "fulfilled" ? user.value : null,
        stats: stats.status === "fulfilled" ? stats.value : null,
        notes: notes.status === "fulfilled" ? notes.value : null,
      });
    });

    return () => controller.abort();
  }, [userId]);

  return <pre>{JSON.stringify(state, null, 2)}</pre>;
}

7. Limitations of AbortController and common pitfalls

AbortController only solves problems for asynchronous operations that actually respect the signal. The Fetch API supports it natively, but older XMLHttpRequest-based libraries or some third-party SDKs do not know this concept and silently ignore a passed signal. In such cases you remain dependent on an ignore flag or a ref-based check, because the underlying request cannot truly be cancelled.

Another pitfall is accidentally reusing an already cancelled controller. An AbortController can only be aborted once, and a new fetch using the same, already-aborted signal fails immediately. That is why the controller must be created fresh inside the effect and must not be reused persistently outside of it, for example in module scope or a ref. Following this rule avoids the most common bugs when working with AbortController.

8. Testing AbortController behavior

When testing with React Testing Library, you can deliberately provoke the cancellation behavior by rendering a component, immediately changing its props (such as the search term), and then verifying that only the result of the last request ends up in the DOM. A mocked fetch that reacts to the passed signal and actually triggers a rejection on abort() makes the test realistic instead of merely appearing green on the surface.

A particularly valuable test explicitly checks that no stale state gets written when props change quickly. To do this, you simulate two fetch calls with different artificial delays, where the first, slower request resolves only after the second, faster one. If the component still shows the result of the second request afterwards, the race-condition protection is demonstrably effective and not just theoretically correct.

test("shows only the result of the latest request", async () => {
  global.fetch = jest.fn((url, { signal }) =>
    new Promise((resolve, reject) => {
      const delay = url.includes("react") ? 10 : 100; // "react" resolves first
      const timer = setTimeout(
        () => resolve({ ok: true, json: async () => ({ items: [{ id: 1, title: url }] }) }),
        delay
      );
      signal.addEventListener("abort", () => {
        clearTimeout(timer);
        reject(new DOMException("Aborted", "AbortError"));
      });
    })
  );

  const { rerender } = render(<SearchResults query="re" />);
  rerender(<SearchResults query="react" />);

  await screen.findByText(/q=react/);
  expect(screen.queryByText(/q=re(?!act)/)).not.toBeInTheDocument();
});

9. Conclusion and comparison of approaches

Both the ignore flag and AbortController reliably solve the underlying problem of stale state updates, but they differ substantially in their side effects. The flag is the simpler, dependency-free variant and works well for small prototypes or situations where the underlying data fetch cannot be cancelled anyway. AbortController is the more robust choice for production applications because it saves bandwidth, reduces server load, and makes behavior transparent in the DevTools.

In practice, AbortController is recommended as the default pattern for all fetch-based effects as soon as an application grows beyond a simple prototype. Anyone additionally using TanStack Query or SWR gets this behavior automatically, since both libraries internally cancel stale requests when query keys change. For all cases where you deliberately work without an extra library, the useAbortableFetch hook shown here remains a solid, maintainable foundation.

10. Summary

11. FAQ: Race Conditions in useEffect: The Essentials at a Glance