Does Node.js automatically propagate AbortSignal to legacy callback‑based APIs?

No — Node.js does not automatically propagate an AbortSignal to legacy callback-based APIs. A function like fs.readFile(path, callback) has no signal parameter and no internal plumbing to watch one. If you abort an AbortController, the underlying file read continues, the callback still fires, and nothing on the Node.js side connects the two.

Why there's no built-in bridge

AbortSignal support in Node.js is opt-in per API. An API only respects a signal if its implementation explicitly checks signal.aborted or listens for the 'abort' event and then tears down the underlying operation. Legacy callback APIs predate AbortController and were never retrofitted with that logic. There is no global registry where the runtime matches signals to in-flight callbacks — the signal is just an event emitter unless some code subscribes to it.

The recommended pattern: wrap, but know the limits

The standard workaround is to wrap the callback API in a Promise and reject early when the signal fires:

function readFileWithSignal(path, signal) {
  return new Promise((resolve, reject) => {
    if (signal.aborted) {
      return reject(signal.reason ?? new Error('Aborted'));
    }
    const onAbort = () => reject(signal.reason ?? new Error('Aborted'));
    signal.addEventListener('abort', onAbort, { once: true });
    require('fs').readFile(path, (err, data) => {
      signal.removeEventListener('abort', onAbort);
      if (err) return reject(err);
      resolve(data);
    });
  });
}

This gives callers correct JavaScript-side semantics — the promise rejects promptly and your await chain unblocks. But be clear about what it does not do:

• The I/O operation keeps running. The OS-level read is not interrupted; the callback still executes internally and consumes resources. You've cancelled your interest in the result, not the work itself.
• Listener hygiene matters. Always remove the 'abort' listener when the operation settles (as above). Adding listeners to a long-lived signal without cleanup is a classic slow memory leak.
• Promise.race has the same caveat. Racing the operation against an abort promise rejects early but leaves the operation detached and running — it's equivalent to the wrapper, not a stronger form of cancellation.

The real fix: use APIs that accept a signal

For file system work, fs.promises.readFile(path, { signal }) accepts an AbortSignal natively and rejects with an AbortError, with the runtime actually participating in the cancellation. The same applies to modern promise-based APIs across the standard library (fetch, streams, timers/promises, child processes via signal options). Where a native option exists, prefer it over any wrapper — that's the only way cancellation reaches the underlying operation.

Verifying the behavior yourself

You can confirm the asymmetry in a minute:

const fs = require('fs');
const ac = new AbortController();

// Legacy: callback still fires after abort
fs.readFile('/some/large/file', () => console.log('callback ran'));
ac.abort();

// Native: rejects with AbortError
fs.promises.readFile('/some/large/file', { signal: ac.signal })
  .catch(e => console.log(e.name)); // 'AbortError'

Bottom line: there is no internal propagation mechanism and no standardized adapter in Node.js. A signal-aware wrapper is the correct pattern for APIs you can't change — just treat it as early rejection of the result, not true cancellation, and migrate to signal-accepting APIs wherever one exists.