Glossary / Abort signals

Abort signals

An AbortSignal is a one-way notification object that communicates cancellation to APIs and application code. It exposes whether cancellation has happened, an abort reason, and an abort event. Signals separate the cancellation request from the work being canceled, allowing a caller to control an operation without knowing its internal implementation.

Listening and composition

async function doWork({ signal }) {
  signal.throwIfAborted();
  const onAbort = () => cleanup();
  signal.addEventListener("abort", onAbort, { once: true });
  try { await perform(signal); }
  finally { signal.removeEventListener("abort", onAbort); }
}

Check signal.aborted or call throwIfAborted() before starting, because a signal may already be aborted when received. Register listeners with { once: true } and remove them when work completes to avoid retention. AbortSignal.any([...]) combines sources and AbortSignal.timeout(ms) creates a timed signal in current runtimes; check compatibility and understand which reason wins.

An abort signal is not a generic cancellation guarantee: the operation must observe it and stop cooperatively. It does not interrupt synchronous code or reverse external side effects. Define how abort errors are translated and whether cancellation is expected, logged, or ignored at the boundary.

Interview questions

  1. What is the difference between controller and signal? Controller triggers abort; signal communicates state/reason to consumers.
  2. Why check aborted before adding work? The signal may already be canceled before the function starts.
  3. Does a signal stop arbitrary code automatically? No; consumers must observe it.
  4. Why remove abort listeners? To release captured state after the operation completes.

References