Throttling to 3G exposed a search race that every unit test had passed

Ownership has to come from somewhere other than await. When the search function suspends at `fetch`, its continuation holds the query string it was called with and nothing about whether that query is still the one on screen. Two keystrokes produce two calls and two independent resumptions, and each one calls `setResults` when its own promise resolves ^[4].

Low, consistent latency keeps arrival order close to send order most of the time, and the author of the post is explicit that this is a habit of fast networks and not a guarantee ^[5]. In the published run, the banana response came back after 210 ms and the apple response after 3001 ms ^[9]. Subtract them and there are 2791 ms in which the older query's response can land on top of the newer one's ^[1].

The server-side delays produced that timing. Chrome's throttling reference no longer lists a separate Slow 3G preset; the entry is now just 3G, sitting between Slow 4G and Offline ^[1]. DevTools 3G throttling applies to every request in the session regardless of which path it takes, so it makes the flip easier to hit without guaranteeing one on any given run ^[7]. To get a failure that reproduces, the author added artificial server-side delays: three seconds for apple, 200 ms for banana. The logged test ran with throttling off, so the numbers came from the delay alone ^[8]. The throttle finds the bug, and an injectable delay is what a test can assert against.

The guard is small. A counter increments on every call, each call keeps its own id, and after the await the function returns early when the id no longer matches the latest ^[10]. The stale response still arrives and is discarded before it reaches state. AbortController is the other option, and the author treats it as a different tradeoff. Aborting stops the client waiting on the old response, but "It doesn't necessarily stop the server from finishing the work it already started," the author wrote ^[11]. Request IDs let the old request finish and then ignore it, which the author chose because the search endpoint is cheap and nothing needed cancelling server-side ^[12].

A client-side timeout produced the second bug. Autosave gave up and retried when it had not heard back within 1.2 seconds. Against saves that normally take a few hundred milliseconds, that is reasonable. A throttled save can take two or three seconds with nothing actually wrong ^[13]. Against a three-second save, the retry fires 1800 ms before the first response could arrive ^[2].

The wider claim in the post is the author's: stale results from out-of-order requests are not unique to search boxes and turn up anywhere a component fires more than one async request over its lifetime ^[14]. The post does not measure how often that happens; the evidence is one app and two bugs in one session ^[3]. I would expect the same pattern in any component that renders an awaited fetch without checking whether its caller is still the current one. The cheapest way to find out in a given codebase is an hour on the 3G preset with one endpoint you can slow down on demand.