Skip to main content
Version: 1.13.1

Function: linkAbortSignals()

linkAbortSignals(sources: readonly (AbortSignal | undefined)[]): { abort: (reason?: unknown) => void; signal: AbortSignal; unlink: () => void; } & Disposable

Defined in: utils.ts:647

Follows one or more caller-provided signals with a plain AbortController, instead of composing them with AbortSignal.any. This is the DOWNSTREAM-side pattern for functions that receive signals of unknown provenance.

Why not AbortSignal.any downstream: a composite over a kTimeout source (an AbortSignal.timeout, or another composite containing one) is pinned STRONGLY in Node's gcPersistentSignals set, and — because composite following is lazy and only activates when the composite itself gets a listener — a composite nobody listens to never aborts and never leaves the set, even after its sources abort or the operation completes (measured: 500/500 retained on Node 22.23/24.19/26.7; see repro-nested.mjs). Linking creates no composite at all, and the strong-listener attach + detach even releases caller-created pinned composites (listener-count drop is an exit condition of the set), so legacy caller shapes are cleaned up too.

Parameters

ParameterTypeDescription
sourcesreadonly (AbortSignal | undefined)[]Signals to follow; undefined entries are ignored.

Returns

{ abort: (reason?: unknown) => void; signal: AbortSignal; unlink: () => void; } & Disposable

signal to hand to fetch & co, abort to fire it directly, and unlink to detach from the sources. Every link MUST be disposed when the operation settles: the Disposable contract supports using when the link's lifetime is lexical; the unlink member covers cases where cleanup is forwarded elsewhere (e.g. a response body's settle hook).