Implement a Debounced Search Input With Race-Condition-Safe Request Cancellation

Q: Implement a Debounced Search Input With Race-Condition-Safe Request Cancellation

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Medium > **How to read this doc:** the real bug this question is testing for — an EARLIER, slower request resolving AFTER a LATER, faster one, and incorrectly overwriting the correct, more recent result — was reproduced directly with a deliberately adversarial real timing setup, not just described in the abstract. ## 1. The problem, restated Debouncing alone only reduces HOW OFTEN a real request fires — it does NOT protect against a genuinely real, separate hazard: once TWO real requests are in flight (which can still happen even with debouncing, if the user types again before the first request has finished), there is no guarantee they resolve in the order they were SENT. A race-condition guard is a separate, additional mechanism needed on top of debouncing. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | Is debouncing alone suffic

The problem

Problem, as an interviewer would state it: "Build a search-as-you-type controller: debounce the input, fire a real API request, and correctly handle the case where an EARLIER request resolves AFTER a LATER one — the UI must always show the result matching the user's most recent input, not whichever request happens to finish first."

Examples:

Code

controller.search("reactjs"); // a slow request
controller.search("react");   // a fast request, made moments later
// even if "reactjs" resolves AFTER "react" does, the displayed result is for "react"

Clarifying questions expected:

Is debouncing alone (only firing the LAST call in a burst) enough, or is a separate race-condition guard also needed?
Should a discarded, stale response still be silently ignored, or surfaced somehow (e.g., logged)?
Would using AbortController to genuinely CANCEL the stale network request be preferable to just ignoring its result?

Code / implementation expected: Yes — real, direct proof with a deliberately adversarial timing setup where the earlier request is slower and the later request is faster.

debounce
async
race-condition
fetch

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for practical JavaScript coding interviews. Difficulty: Medium

How to read this doc: the real bug this question is testing for — an EARLIER, slower request resolving AFTER a LATER, faster one, and incorrectly overwriting the correct, more recent result — was reproduced directly with a deliberately adversarial real timing setup, not just described in the abstract.

1. The problem, restated

Debouncing alone only reduces HOW OFTEN a real request fires — it does NOT protect against a genuinely real, separate hazard: once TWO real requests are in flight (which can still happen even with debouncing, if the user types again before the first request has finished), there is no guarantee they resolve in the order they were SENT. A race-condition guard is a separate, additional mechanism needed on top of debouncing.

2. Clarifying questions

The solution is hidden so you can try first

7 min read · 9 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal, direct proof: an earlier, slower request that resolves after a later, faster one is correctly discarded by the race-condition guard