You are writing your own promise-returning function that accepts an AbortSignal. What must it do to honour that signal correctly, and what goes wrong if you get it wrong?

## The contract An abortable function conventionally takes the signal in an options bag — `doWork(input, { signal })` — treats it as optional, and guarantees that after an abort it settles promptly with `signal.reason`. Meeting that guarantee takes four steps, and each has a distinct failure mode. ## 1. Pre-check, because the event may already be gone The `abort` event fires exactly once, at the moment `abort()` is called. If the signal was aborted before your function ran, subscribing gets you nothing — you would wait forever for an event that already happened. ```js signal?.throwIfAborted(); // throws signal.reason if already aborted ``` Inside a promise executor this is especially neat: a synchronous throw in the executor rejects the returned promise, so the pre-check and the abort path produce the same rejection value with no special-casing. Outside an executor, in an async function, `throwIfAborted()` rejects the returned promise for the same reason. The failure mode of skipping it: a caller that cancels early still pays for the whole operation. In a fast-typing search box where every keystroke aborts the previous request, the aborted-before-start case is not an edge case — it is most of the traffic. ## 2. Subscribe, and reject with the reason ```js const onAbort = () => { stopTheWork(); reject(signal.reason); }; signal.addEventListener('abort', onAbort, { once: true }); ``` Reject with `signal.reason` verbatim. Inventing `new Error('aborted')` destroys the caller's ability to classify the rejection: their `err.name === 'AbortError'` check now fails, so your cancellation is reported and retried as a genuine failure. ## 3. Stop the work, not just the promise Rejecting the promise only ends the caller's wait. If the timer keeps ticking, the socket stays open, or the worker keeps computing, you have abandoned the result while still paying for it — and the work may later touch state the caller assumes is finished. The abort handler is where you `clearTimeout`, close the handle, or tear down whatever the operation acquired. When your function is itself a composition of other abortable calls, the right move is to pass the same signal down so cancellation propagates instead of stopping at your layer. ## 4. Clean up the listener This is the one that leaks. Signals are frequently *scoped*, not per-operation: one controller per component, per page view, per request. That signal can live for minutes while hundreds or thousands of short operations run against it. Every `addEventListener('abort', ...)` you never remove stays on the signal's listener list, and the listener closure keeps alive everything it captured — the `reject` function, the operation's buffers, its result object. ```js const id = setTimeout(() => { signal?.removeEventListener('abort', onAbort); resolve(); }, ms); ``` `{ once: true }` only removes the listener when the event *fires*. On the happy path it never fires, so you must remove it explicitly. Wrapping the whole body and removing in a `finally` is the tidier form when you are in an async function. The symptom in production is a heap that grows in proportion to operation count rather than to concurrency, with retained closures rooted at a long-lived signal. ## Settle-once discipline Both paths race: the work may finish microseconds before the abort arrives. Promises absorb this — the second `resolve`/`reject` is ignored — so the promise itself is safe. Your *side effects* are not. `clearTimeout` on a timer that already fired is harmless, but closing a handle you already returned to a pool, or decrementing a counter twice, is not. Make the abort handler idempotent, or guard it with a `settled` flag. ## Do not swallow A tempting shortcut is to `resolve(undefined)` on abort so callers do not need a catch. This is worse than it looks: the caller cannot distinguish "cancelled" from "legitimately produced no result", and downstream code proceeds on a value that was never computed. Reject. ## Optional by default Treat `signal` as optional — `signal?.throwIfAborted()`, `signal?.addEventListener(...)` — so the function stays usable without one. Uniform optional handling also means a caller can wire cancellation later without your signature changing.