Promise.race settles with whichever input promise settles first, so racing the real work against a setTimeout rejection gives you a deadline. The rejection message becomes the error your callers see, so make it descriptive (which call timed out, and how long was the budget). The downside of this minimal version is that the timer keeps running even after the underlying promise resolves, briefly delaying process exit in scripts and leaking timers in long-lived servers. Reach for the cleanup variant in production code.

The .finally(() => clearTimeout(timer)) clears the pending timer once the race settles either way, so a fast resolve no longer leaves a dangling timeout that can keep the Node event loop alive. This matters for command-line scripts that wait for the loop to drain before exiting, and for tests that assert no leaked timers. The behavior on the failing path is unchanged: when the timer fires first, the underlying promise still runs to completion, just with its result discarded.

Racing two promises only stops listening for the loser; the actual network or compute keeps running until it finishes. Threading an AbortSignal through the work lets the timeout abort the underlying request when the deadline fires, freeing sockets and CPU instead of just dropping the result on the floor. The pattern composes cleanly with fetch(url, { signal }) and any helper that follows the abort convention. Without this step, a chatty server can pile up zombie requests behind the user's back.