Implement search where slower earlier responses cannot overwrite newer results.

• Use one effect setup/cleanup cycle for each normalized query value.
• Clear the debounce timer and abort the request during cleanup.
• Increment request identity even when the new query is too short so older work loses ownership immediately.
• Treat abort as expected control flow; only the newest non-abort failure may render an error.
• Keep the request function stable or include it in the effect dependencies.
• Expose loading and result counts accessibly without moving keyboard focus.

1. Normalize the query before deciding whether work is needed.
2. Allocate a monotonically increasing generation for every effect run. That generation is the authority to commit results.
3. If the term is too short, synchronously return to idle and clear old results; cleanup from the previous render still aborts its work.
4. Create an AbortController and schedule the request after 300 ms.
5. On success or failure, compare the captured generation with the latest generation before changing state.
6. In cleanup, clear the timer and abort. Abort saves resources; generation checking guarantees UI correctness even if cancellation is ignored.
7. Verify the race with controllable promises resolved in the wrong order, not only with a happy-path mocked fetch.

import { useEffect, useRef, useState } from "react";

type Person = { id: string; name: string };
type SearchStatus = "idle" | "waiting" | "loading" | "success" | "error";

type Props = {
  searchPeople: (term: string, signal: AbortSignal) => Promise<Person[]>;
};

export function PeopleSearch({ searchPeople }: Props) {
  const [query, setQuery] = useState("");
  const [results, setResults] = useState<Person[]>([]);
  const [status, setStatus] = useState<SearchStatus>("idle");
  const [error, setError] = useState<string | null>(null);
  const latestGeneration = useRef(0);

  useEffect(() => {
    const term = query.trim();
    const generation = ++latestGeneration.current;

    if (term.length < 2) {
      setResults([]);
      setError(null);
      setStatus("idle");
      return;
    }

    const controller = new AbortController();
    setError(null);
    setStatus("waiting");

    const timer = window.setTimeout(async () => {
      if (generation !== latestGeneration.current) return;
      setStatus("loading");

      try {
        const people = await searchPeople(term, controller.signal);
        if (generation !== latestGeneration.current) return;

        setResults(people);
        setStatus("success");
      } catch (caught) {
        const isAbort =
          controller.signal.aborted ||
          (caught instanceof DOMException && caught.name === "AbortError");

        if (isAbort || generation !== latestGeneration.current) return;

        setResults([]);
        setError("Search failed. Try again.");
        setStatus("error");
      }
    }, 300);

    return () => {
      window.clearTimeout(timer);
      controller.abort();
    };
  }, [query, searchPeople]);

  return (
    <section aria-label="People search">
      <label htmlFor="people-query">Search people</label>
      <input
        id="people-query"
        type="search"
        value={query}
        onChange={(event) => setQuery(event.target.value)}
        aria-describedby="search-status"
      />

      <p id="search-status" role="status" aria-live="polite">
        {status === "waiting" ? "Waiting for typing to stop" : null}
        {status === "loading" ? "Searching" : null}
        {status === "success" ? `${results.length} results` : null}
        {status === "error" ? error : null}
      </p>

      <ul>
        {results.map((person) => <li key={person.id}>{person.name}</li>)}
      </ul>
    </section>
  );
}

In a production application, a query library may own caching, deduplication, retries, and cancellation. The same interview reasoning still applies: normalize the key, debounce deliberately, and ensure only the current key may publish data.

Each keystroke does constant local work; rendering a successful result is O(n) for n people. Debouncing reduces request volume but intentionally adds 300 ms of latency after typing. Aborting can save browser and server work, but it is not a correctness guarantee because a response may already be complete or a custom transport may ignore the signal. Request identity is the final commit guard. Caching repeated terms can improve latency, but cache ownership belongs outside this small component once invalidation and deduplication matter.

• Whitespace-only input and a one-character normalized term.
• The first request resolves after a newer request succeeds.
• The old transport rejects after abort with a nonstandard error.
• The newest request fails while an older successful response is still pending.
• The component unmounts during the debounce window or an active request.
• React development Strict Mode performs an extra setup/cleanup cycle.
• The searchPeople prop changes identity every render and unintentionally restarts the effect.
• Duplicate result IDs break stable list rendering.

• Use fake timers to prove no request occurs before 300 ms and rapid edits create only one request.
• Make request promises controllable; resolve B before A and assert A never replaces B.
• Use a fake transport that ignores abort to prove the generation guard independently.
• Clear the query while a request is active and assert the UI returns to idle immediately.
• Reject an aborted request and assert no error appears; reject the current request and assert the error does appear.
• Unmount during waiting and loading, then verify timers are cleared and the signal is aborted.

• Old results replace new ones: debounce was implemented, but response ownership was not.
• An error flashes while typing: an aborted or stale rejection was allowed to commit.
• Requests fire twice in development: cleanup does not mirror setup, so Strict Mode exposes leaked timers or work.
• Clearing the field leaves old results: the short-query branch exits without resetting visible state or invalidating the old generation.
• The debounce never settles: the request function is recreated every render and remains an unstable dependency.
• Only the happy-path test passes: promises were resolved in request order, so the race condition was never exercised.