A search box fires a fetch on every keystroke and renders whatever comes back. Users occasionally see results for a query they have already replaced. What is happening, and how do you fix it?

## The failure Say the user types `ca`, then `cat`. Two requests go out, roughly 100 ms apart. The first hits a cold cache and takes 900 ms; the second is served from a warm one and takes 120 ms. `cat`'s results render first and look correct. Then `ca`'s results arrive and overwrite them. The user is now looking at results for a query that no longer exists in the box, and the display corrects itself only on the next keystroke. The bug is intermittent, is invisible on a fast local network, and is one of the most common real defects in typeahead UIs. The root cause is simply that **completion order is not dispatch order**. Nothing in the platform promises that two independent requests finish in the order they were started; server-side variance, cache hits, connection reuse and packet loss all reorder them freely. ## Half one: cancel the previous request ```js let controller = null; function search(query) { controller?.abort(); // stop the previous one controller = new AbortController(); // a fresh one for this request return fetch('/api/search?q=' + encodeURIComponent(query), { signal: controller.signal, }); } ``` The controller must live **outside** the function so it survives between keystrokes — a controller created inside and never stored cancels nothing. And it must be a **new** controller each time: `AbortSignal` is single-use, so a signal that has already aborted keeps `aborted === true` forever, and passing it to a later `fetch()` makes that request reject immediately without ever going out. Cancelling gives you three things: the stale response never arrives to overwrite anything, the browser stops downloading a payload nobody wants, and — if the server honours the disconnect — work stops server-side too. ## Handling the rejection Aborting a fetch makes it reject. That rejection is expected, and it is not a failure to surface: ```js try { const res = await search(query); render(await res.json()); } catch (err) { if (err.name !== 'AbortError') throw err; // real failures still bubble } ``` The classic bug at this step is a `catch` that flips the UI into an error state on every keystroke, because each new keystroke cancels the previous request and the cancellation is reported as if the server had failed. ## Half two: guard, because abort is not retroactive Cancellation is a race of its own. If the previous response had already resolved when `abort()` was called, aborting does nothing to it — the data is delivered and its handler is already queued to run. Body parsing widens the window further: `fetch()` resolves at the headers, and the `await response.json()` that follows is a second suspension point in which the state can change underneath you. So keep a stamp: ```js let latest = ''; // ... latest = query; const data = await res.json(); if (query !== latest) return; // a newer query has superseded this one render(data); ``` A monotonically increasing sequence number works identically and is better when the same query can legitimately be re-issued. Either way the rule is: **the response identifies itself, and the consumer decides whether it is still wanted.** Cancellation is the optimisation; the guard is the correctness. ## Teardown The same controller should be aborted when the widget goes away — the user navigates, the panel closes, the component unmounts. Otherwise an in-flight response resolves into a handler that writes to state nobody is watching, keeps the parsed payload and its closure alive, and in some frameworks produces a warning or an outright error. ## What does not fix it Debouncing reduces the number of requests, which is worth doing, but it does not order them: two requests that both survive the debounce race exactly as before. A per-request delay or an artificial `Promise` ordering does not help either, because the problem is not your code's ordering — it is the network's. Only cancel-plus-guard closes it.