Implement a Cancelable Promise (with CancelToken / AbortController)

Q: Implement a Cancelable Promise (with CancelToken / AbortController)

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Hard > **How to read this doc:** the critical, real distinguishing claim — that cancellation genuinely stops the underlying work rather than merely having the caller ignore a stale, still-arriving result — was verified directly by measuring REAL elapsed time: the promise rejected in about 20ms, not anywhere near its original 1000ms delay. ## 1. The problem, restated A GENUINELY cancelable async operation must, on cancellation, actually stop its own underlying work (clear a pending timer, abort an in-flight real network request) — not merely let the CALLER discard a result that the operation keeps computing anyway in the background. `AbortController`/`AbortSignal` is the real, standard platform primitive for this. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | Genuine cancellation, or caller-side ignoring? | A real, meaningful dist

The problem

Problem, as an interviewer would state it: "Implement a cancelable async operation using AbortController/AbortSignal — aborting it should genuinely stop the underlying work, not just have the caller ignore a late result."

Examples:

Code

const controller = new AbortController();
const p = cancelableDelay(5000, controller.signal);
controller.abort(); // p rejects almost immediately, the real underlying timer is cleared

Clarifying questions expected:

Does "cancel" mean genuinely stopping the underlying work (clearing a timer, aborting a real fetch), or just having the CALLER ignore a result that still arrives later?
What should happen if the signal is ALREADY aborted before the operation even starts?
Should the rejection use a specific, real, standard error type/name, for callers to distinguish an intentional cancellation from a genuine failure?

Code / implementation expected: Yes — real, direct proof that aborting mid-flight causes a genuinely FAST rejection, not one that waits for the original, full duration to elapse.

promise
cancelable
abort

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: Hard

How to read this doc: the critical, real distinguishing claim — that cancellation genuinely stops the underlying work rather than merely having the caller ignore a stale, still-arriving result — was verified directly by measuring REAL elapsed time: the promise rejected in about 20ms, not anywhere near its original 1000ms delay.

1. The problem, restated

A GENUINELY cancelable async operation must, on cancellation, actually stop its own underlying work (clear a pending timer, abort an in-flight real network request) — not merely let the CALLER discard a result that the operation keeps computing anyway in the background. AbortController/AbortSignal is the real, standard platform primitive for this.

2. Clarifying questions a strong candidate asks

| Question | Why it

The solution is hidden so you can try first

6 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: aborting mid-flight causes a genuinely fast rejection (~20ms), not one that waits for the original full delay to elapse