Why does JavaScript have no promise.cancel(), and what does AbortController give you instead?

## What a promise actually is A promise is a *one-shot, write-once container for a future result*, with two capabilities split apart: - The **producer** capability — the `resolve` and `reject` functions — is handed only to the executor passed to `new Promise(...)`. Once the executor returns, nobody else has a reference to them unless it deliberately leaked one. - The **consumer** capability — `.then`, `.catch`, `.finally`, and `await` — is what everybody else gets. It is strictly read-only: you can register interest in the outcome, and that is all. ```js const p = new Promise((resolve, reject) => { // only this scope can decide the outcome }); p.cancel; // undefined — there is no such method ``` That split is not an oversight; it is the invariant that makes promises composable. If any holder could settle a promise, no code could rely on the outcome it was promised. ## Why a cancel() method would be unsound Three properties of promises make consumer-side cancellation incoherent: 1. **Settle-once.** A promise transitions from pending to fulfilled or rejected exactly once and then never changes. A `cancel()` would be a third outcome that every existing consumer would have to be taught to handle. 2. **Many consumers, one result.** A promise can be awaited from arbitrarily many places, and each `.then()` creates a *new* promise downstream. There is no single owner. If one consumer cancelled, the others would lose a result they were legitimately waiting for, through no action of their own. 3. **The result is detached from the work.** By the time you hold a promise, the operation has usually already started, and the promise carries no reference back to it. Cancelling the handle could not reach the work anyway. TC39 did explore a cancellable-promise design, with a distinct "cancelled" state and a cancel token; it was withdrawn rather than shipped, and the ecosystem converged on signalling instead. ## The AbortController answer The standard alternative inverts the direction. Instead of reaching backwards from the result, you pass a cancellation channel *forwards* into the operation before it starts: ```js const controller = new AbortController(); const promise = doWork(input, { signal: controller.signal }); controller.abort(new Error('no longer needed')); // doWork observes the signal, stops, and rejects with that reason ``` The promise's contract is untouched: it still settles once, it just settles as a rejection whose reason is `signal.reason`. Every existing `.catch` and `try/catch` keeps working; there is no new state to learn. ## What abort does not do Cancellation in JavaScript is **cooperative**. `abort()` sets a flag and fires an event — nothing more: - Code that never looks at the signal is unaffected. A `while` loop crunching numbers, or a library function with no `signal` option, runs to completion regardless. - Side effects already performed are not undone. If the operation already wrote a row or sent bytes on the wire, aborting the client-side promise does not reach back and unwind them. - Nothing is preempted mid-statement. Run-to-completion still holds: the current synchronous job finishes before any abort listener that was queued as a task runs — though the `abort` event itself dispatches synchronously inside `abort()`. ## The await limitation This is the sharp edge candidates miss. `await p` resumes only when `p` settles. There is no way for a signal to interrupt an `await` from the outside; if the awaited promise never settles, the async function never resumes, and its local state stays alive. So the abort has to be visible *in the thing you are awaiting*. Either the operation itself accepts the signal and rejects on abort, or you await something composed with a promise that rejects when the signal fires: ```js function rejectOnAbort(signal) { return new Promise((_, reject) => { signal.throwIfAborted(); signal.addEventListener('abort', () => reject(signal.reason), { once: true }); }); } ``` Bailing out this way makes *your* code stop waiting; it does nothing to stop the underlying work, which keeps running unobserved. That distinction — abandoning a result versus genuinely stopping the operation — is exactly what an interviewer is listening for. ## One more consequence Because abort surfaces as a rejection, an aborted operation whose promise has no rejection handler is a plain unhandled rejection. Cancellation being "expected" does not exempt it from being caught.