Handling Race Conditions in Data Fetching

The plain-language idea

A search box that fires a new request on every keystroke is the classic case: type "r", "re", "rea", and three requests are now in flight for the same logical query. Network timing is not guaranteed to match request order — the "r" request can take longer than the "rea" request and resolve last. If nothing accounts for this, the slow, stale "r" response arrives after the correct "rea" response and overwrites it, and the UI ends up showing results for a query the user no longer has typed.

There are two real, concrete fixes:

• Cancel the previous request with AbortController. Each new request gets its own controller; starting a new request explicitly aborts the previous in-flight one for the same logical query first. If the aborted request's response somehow still arrives, it's ignored because it was cancelled.
• Track a sequence number and check it on arrival. Increment a counter on every new request, and have each response check whether its id still matches the latest before applying its result. This works even in a context where cancelling the underlying request isn't practical — only ignoring a stale result is.

See it in a real thing: a search box useEffect

function useSearchResults(query: string) {
  const [results, setResults] = useState<Result[]>([]);

  useEffect(() => {
    if (!query) return;

    const controller = new AbortController();

    fetch(`/api/search?q=${encodeURIComponent(query)}`, { signal: controller.signal })
      .then((res) => res.json())
      .then((data) => setResults(data))
      .catch((err) => {
        if (err.name !== "AbortError") throw err; // a real failure, not a cancellation
      });

    // Cleanup runs before the next effect fires (i.e. before the next
    // request starts) AND on unmount — both cases should cancel this one.
    return () => controller.abort();
  }, [query]);

  return results;
}

Where AbortController isn't available or convenient (a library call that doesn't expose a signal, for instance), the sequence-number version does the same job without cancellation:

function useSearchResults(query: string) {
  const [results, setResults] = useState<Result[]>([]);
  const latestId = useRef(0);

  useEffect(() => {
    if (!query) return;
    const requestId = ++latestId.current;

    searchLibrary.search(query).then((data) => {
      if (requestId === latestId.current) {
        setResults(data); // still the latest request — safe to apply
      }
      // else: a newer request has since started, so this response is stale — drop it
    });
  }, [query]);

  return results;
}

What people usually miss

Watch out

• This isn't about requests failing — every request here can succeed. The bug is purely about arrival order not matching send order; both responses are individually valid, and the wrong one just happens to arrive second.
• An aborted fetch throws, and that throw needs to be told apart from a real failure. Catching every error identically and showing "search failed" on an intentional cancellation is a real, easy-to-ship bug — check the error's abort signal before treating it as a genuine failure.
• The sequence-number approach doesn't stop the wasted request from happening, it just stops the wasted response from being applied — AbortController is strictly better when it's available, because it can actually cancel the in-flight work.
• This bug only shows up under real network variability, so it's easy to miss entirely in local development, where requests are fast and usually resolve in the order they were sent — testing with throttled network conditions is what actually surfaces it.
• The same pattern applies beyond search boxes — any UI that can trigger a new fetch for the same logical data before the last one resolves (rapid filter changes, tab switches, quick pagination clicks) has this exact race.

Why this matters in interviews

"A user types quickly in a search box and sometimes sees results for an earlier, different query — what's happening and how do you fix it?" is a real, common debugging question, and naming the out-of-order-arrival cause plus a concrete fix (AbortController or a sequence check) is what separates a candidate who's hit this bug from one who hasn't.