A JavaScript helper adds a timeout by racing an operation against a rejecting timer: `const timeout = (ms) => new Promise((_, reject) => setTimeout(() => reject(new Error('timed out')), ms)); const data = await Promise.race([slowRequest(), timeout(1000)]);`. If slowRequest() takes 5 seconds, what does the caller observe, and what happens to slowRequest() itself?

## What the race actually does `Promise.race(iterable)` walks the iterable once, resolves each entry to a promise and attaches internal handlers to every one of them. It returns a new promise that adopts the state of whichever input settles first — fulfilled or rejected. Every later settlement is ignored, because the race promise is already settled and a promise settles exactly once. That is the whole mechanism, and it explains both halves of the answer. At 1000 ms the timer promise rejects, so the race promise rejects, so `await` throws inside the caller. At 5000 ms `slowRequest()` fulfils, the race promise is already settled, and the value goes nowhere. ```js const timeout = (ms) => new Promise((_, reject) => setTimeout(() => reject(new Error('timed out')), ms)); try { const data = await Promise.race([slowRequest(), timeout(1000)]); } catch (err) { console.log(err.message); // 'timed out' at ~1000 ms } // slowRequest() is still running here and will finish at ~5000 ms ``` ## The operation was already started A promise in JavaScript is not a description of work to be done later — it is a handle on work that has *already begun*. By the time the array literal `[slowRequest(), timeout(1000)]` is evaluated, `slowRequest()` has been called and its request is in flight. Nothing in the promise API gives a consumer a way to reach back and stop the producer, so a raced timeout can only change what the *caller* waits for. The practical consequences are worth saying out loud in an interview: - The remote server, database, or file handle is still busy. A timeout wrapper protects your caller's latency, not your dependency's load. - If the operation holds a resource — a pooled connection, a lock, a large buffer — that resource stays held until it finishes naturally. - Retrying immediately after a raced timeout means two copies of the work are now in flight, which is exactly how a slow dependency becomes an overloaded one. ## The loser's late rejection is handled, but silent A common follow-up is whether a loser that rejects later triggers an unhandled rejection. It does not: `race` attached a rejection handler to every input, so the runtime sees the rejection as handled. The downside is the opposite problem — the error vanishes entirely. If you care about diagnosing those, attach your own handler before racing: ```js const work = slowRequest(); work.catch((err) => console.warn('late failure after timeout:', err)); const data = await Promise.race([work, timeout(1000)]); ``` Note that you must race the *same* promise value you attached the handler to, not a second call to `slowRequest()`. ## Clean up the timer The naive helper leaks a pending timer whenever the operation wins the race. The callback then fires later and calls `reject` on a promise nobody is listening to — harmless in itself — but the timer is real: in Node a pending `setTimeout` keeps the event loop alive, so a script that has finished its work can sit there for the remaining seconds, and in a hot path you accumulate thousands of live timers. Clear it once the race is decided: ```js function withTimeout(promise, ms, message = 'operation timed out') { let timer; const fuse = new Promise((_, reject) => { timer = setTimeout(() => reject(new Error(message)), ms); }); return Promise.race([promise, fuse]).finally(() => clearTimeout(timer)); } ``` `finally` runs on both outcomes and passes the original value or rejection straight through, which is exactly the semantics a wrapper wants. ## Making the timeout mean something If the underlying work must actually stop, the operation has to cooperate: it needs to accept a signal or expose its own cancel path, and the wrapper triggers it when the deadline passes. A raced timer is the right tool only when abandoning the result is genuinely acceptable — a cheap read, a best-effort enrichment, a panel the UI can render without. When the operation is expensive or has side effects, an abandoned-but-still-running call is a bug waiting to happen. Also give the rejection a recognisable shape. `new Error('timed out')` is fine for a demo, but callers usually need to distinguish “we gave up” from “the server said no” — a dedicated error subclass or a `code` property makes the wrapper composable with logic that should treat timeouts differently from validation failures.