Node.js Async Control-Flow, Errors & Context Propagation

Parent: JavaScript and Node.js · Published reference · snapshot 2026-09-08 · skill lang-js-ts/references/nodejs-async-patterns-error-context.md

↓ Facts as markdown all context files

This reference is the layer above basic promises. Once you can await, three problems

These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.

Overview

This reference is the layer above basic promises. Once you can await, three problems remain: how do you cancel an in-flight operation, how do you carry structured error information (not just a string), and how do you keep per-request context (a request id, a trace span, a tenant) alive as control hops across await points, timers, and callbacks. Cancellation, structured errors, and async context are what this file covers. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#overview]
It defers three adjacent topics: the intro layer (what a promise is, async/await, .then/.catch) → javascript-nodejs; the libuv event-loop phase model, microtask-vs-macrotask ordering, and process.nextTick starvation → nodejs-concurrency-internals; and diagnostics_channel / channel.bindStore() / TracingChannel for APM-style instrumentation → nodejs-diagnostics-profiling (this file uses AsyncLocalStorage for your own request context). [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#overview]
The mental model: a unit of async work should be cancellable (carries an AbortSignal), should fail with a typed, chainable error (carries code + cause), and should run inside a context (AsyncLocalStorage) any nested async call can read without threading an argument through every function. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#overview]

1. Cancellation — `AbortController` / `AbortSignal`

AbortController is the standard cancellation primitive (Web-platform, available globally in Node - no import). A controller owns one signal; calling controller.abort(reason) flips signal.aborted to true, records signal.reason, and fires the 'abort' event. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#1-cancellation-abortcontroller-abortsignal]
- The signal is the cancellation token. Pass signal into the options of any abort-aware API: fetch(url, { signal }), node:timers/promises (setTimeout(ms, value, { signal })), fs.readFile(path, { signal }), events.once(emitter, name, { signal }), and stream/pipeline operations. The API rejects (or rejects the awaited promise) with an AbortError (err.code === 'ABORT_ERR') - or with your custom reason if you passed one to abort(). [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#1-cancellation-abortcontroller-abortsignal]
- signal.reason is whatever you passed to abort(reason); if you passed nothing it defaults to a DOMException named AbortError. signal.throwIfAborted() throws that reason immediately - call it at the top of and between steps in a long async function so a late-arriving cancellation short-circuits. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#1-cancellation-abortcontroller-abortsignal]
- 'abort' event: register a listener (with { once: true }) to run teardown that the awaited API can't do for you (close a file you opened, roll back). [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#1-cancellation-abortcontroller-abortsignal]

2. Composing signals — `AbortSignal.timeout()` and `AbortSignal.any()`

The two static factories are what make cancellation composable: [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#2-composing-signals-abortsignaltimeout-and-abortsignalany]
- AbortSignal.timeout(ms) returns a signal that auto-aborts after ms (with a TimeoutError reason). It does not keep the event loop alive - it won't, by itself, prevent the process from exiting. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#2-composing-signals-abortsignaltimeout-and-abortsignalany]
- AbortSignal.any([...signals]) returns a signal that aborts as soon as any input aborts, adopting that signal's reason. This is how you OR together a request-deadline and a user-cancel: [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#2-composing-signals-abortsignaltimeout-and-abortsignalany]
AbortSignal.abort(reason) returns an already-aborted signal - handy for tests or for passing "already cancelled" into a function uniformly. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#2-composing-signals-abortsignaltimeout-and-abortsignalany]

3. Structured errors — `Error.cause`, `AggregateError`, custom classes

A thrown string loses information. Node + modern JS give you three structuring tools: [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#3-structured-errors-errorcause-aggregateerror-custom-classes]
- Error.cause - the second-argument options bag: new Error('msg', { cause }). It chains a low-level failure to a higher-level one without flattening the message, and util.inspect/stack printing walks the chain. Re-throw with context, keep the original: [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#3-structured-errors-errorcause-aggregateerror-custom-classes]
- AggregateError - holds multiple errors in err.errors (an array). This is exactly what Promise.any rejects with when every input rejects, and the right type to throw when you've collected several failures (see Promise.allSettled below). [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#3-structured-errors-errorcause-aggregateerror-custom-classes]
- Custom error classes - subclass Error, set a stable code, and (optionally) carry cause. Always set name and code: [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#3-structured-errors-errorcause-aggregateerror-custom-classes]

4. The `error.code` convention — match on code, never message

Node attaches a stable string code to its errors (ERR_INVALID_ARG_TYPE, ABORT_ERR, ENOENT, ECONNREFUSED, …). The docs are explicit: error.code changes only across major Node versions, while error.message may change in any version. Branch on code, not on the message - message matching is a latent bug that breaks on upgrade and across locales. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#4-the-errorcode-convention-match-on-code-never-message]

5. Process-level failure — rejections, exceptions, and exit semantics

Two process events are the safety net of last resort: [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#5-process-level-failure-rejections-exceptions-and-exit-semantics]
- 'unhandledRejection' (reason, promise) - a Promise rejected with no handler attached within a turn of the loop. 'rejectionHandled' (promise) fires if a handler is attached later - track a Map keyed by the promise to reconcile the two (add on unhandledRejection, delete on rejectionHandled) and report only the survivors. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#5-process-level-failure-rejections-exceptions-and-exit-semantics]
- 'uncaughtException' (err, origin) - an exception bubbled to the loop with no try/catch. 'uncaughtExceptionMonitor' observes it without changing the crash-or-not behavior (use it to log to an APM, then let the normal handling run). [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#5-process-level-failure-rejections-exceptions-and-exit-semantics]
Why uncaughtException must generally be fatal. The docs state it plainly: an uncaught exception means the app is in an undefined state; 'uncaughtException' is not an On Error Resume Next. The correct use is synchronous cleanup of resources (flush a log, release file descriptors) and then exit - let an external supervisor restart the process. Resuming after it is unsafe. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#5-process-level-failure-rejections-exceptions-and-exit-semantics]
Exit semantics. Prefer setting process.exitCode = n and letting the loop drain naturally over process.exit(n), which terminates synchronously and can truncate buffered stdout/stderr. The 'exit' event handler may run synchronous code only - queued async work is abandoned the instant it returns. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#5-process-level-failure-rejections-exceptions-and-exit-semantics]
--unhandled-rejections=<mode> controls rejection handling: throw (the default since Node 15 - emit the event, else raise as an uncaught exception), strict (always raise as uncaught), warn (always warn, never throw), warn-with-error-code (warn and set a nonzero exit code), and none (silence entirely). [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#5-process-level-failure-rejections-exceptions-and-exit-semantics]

6. Promise concurrency — `all` vs `allSettled` vs `any` vs `race`

The four combinators differ on fail-fast vs collect-all and on fulfillment vs first-settled: [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#6-promise-concurrency-all-vs-allsettled-vs-any-vs-race]
The teaching point: all is fail-fast (one rejection abandons the others' results), allSettled is collect-all (you get every outcome, success and failure, and inspect status). Use all when any failure should abort the batch; use allSettled for "do all of these, then tell me what worked." race settles on the first outcome of either kind; any ignores rejections until a fulfilment (or gives you an AggregateError). [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#6-promise-concurrency-all-vs-allsettled-vs-any-vs-race]
Concurrency limiting. Promise.all(items.map(fn)) fires all tasks at once - fine for 10, a thundering herd for 10,000 (socket exhaustion, rate-limit bans). Cap in-flight work with a pool (a small worker-count loop pulling from a shared iterator, or a library like p-limit). This is the practical complement to the combinators. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#6-promise-concurrency-all-vs-allsettled-vs-any-vs-race]

7. Context propagation — `AsyncLocalStorage` (+ `async_hooks`/`AsyncResource`)

AsyncLocalStorage (from node:async_hooks) carries a value through an async call chain without threading it as a parameter - the canonical use being a per-request id or trace context that any nested function can read: [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#7-context-propagation-asynclocalstorage-async_hooksasyncresource]
- run(store, cb, ...args) is the API you want 95% of the time: it scopes store to cb and every async operation spawned inside it, then restores the previous store. Nested run calls shadow cleanly. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#7-context-propagation-asynclocalstorage-async_hooksasyncresource]
- getStore() returns the current store (or undefined outside any run). [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#7-context-propagation-asynclocalstorage-async_hooksasyncresource]
- enterWith(store) sets the store for the rest of the current synchronous execution and onward - with no automatic exit. The docs warn this leaks easily (e.g. a second event-handler on the same emitter inherits it). Prefer run(); reach for enterWith() only with a strong reason. exit(cb) runs cb outside the store; disable() tears the instance down. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#7-context-propagation-asynclocalstorage-async_hooksasyncresource]
- AsyncLocalStorage.snapshot() captures the current context and returns a function that re-enters it later - useful for re-binding a callback to the context it was created in without a full AsyncResource. AsyncLocalStorage.bind(fn) wraps a function so it always runs in the captured context. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#7-context-propagation-asynclocalstorage-async_hooksasyncresource]
- Performance / when to use. It is the recommended, stable, optimized mechanism - far better than rolling your own with async_hooks. It is not free (context tracking has a measured cost), so use it for genuinely cross-cutting state (request id, trace, tenant), not as a general-purpose variable bag. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#7-context-propagation-asynclocalstorage-async_hooksasyncresource]
When the context is lost, the propagation broke at a boundary AsyncLocalStorage can't see - a callback queued by native/3rd-party code, an object-pool worker, or a long-lived emitter. That is the job of async_hooks and AsyncResource, the low-level layer: [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#7-context-propagation-asynclocalstorage-async_hooksasyncresource]
- async_hooks.createHook({ init, before, after, destroy }) registers lifecycle callbacks for every async resource; executionAsyncId() / triggerAsyncId() expose the current resource and the one that scheduled it. This is the machinery AsyncLocalStorage is built on. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#7-context-propagation-asynclocalstorage-async_hooksasyncresource]
- AsyncResource is the piece you actually use directly: wrap a callback that will be invoked later (from a connection pool, a cache, a custom emitter) so it runs in the correct context. Construct new AsyncResource('MyThing') and call resource.runInAsyncScope(cb, thisArg, ...args), or wrap once with the static AsyncResource.bind(fn). This is how you re-attach context across a pool boundary. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#7-context-propagation-asynclocalstorage-async_hooksasyncresource]
- Caveat: async_hooks is Stability 1 (experimental) and low-level; the docs explicitly discourage using the hook API directly and steer you to AsyncLocalStorage for context tracking. Use AsyncResource.bind for the pool-callback case; avoid building context systems on raw createHook. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#7-context-propagation-asynclocalstorage-async_hooksasyncresource]

Practical patterns

util.promisify(fn) converts an error-first callback function (…, (err, value) => …) into a promise-returning one; util.callbackify(fn) does the reverse for an async function. If a function ships a better promise form, it advertises it on the util.promisify.custom symbol and promisify returns that instead of wrapping the callback. (Most core modules already expose node:fs/promises etc. - promisify is for third-party or legacy callback APIs.) [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#practical-patterns]
Thread one signal through a whole operation. Accept { signal } in your own async functions, call signal.throwIfAborted() between steps, and forward the same signal to every downstream call (fetch, timers, fs) so one abort() unwinds the entire tree. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#practical-patterns]
Time-box with AbortSignal.any([userSignal, AbortSignal.timeout(ms)]) instead of racing a manual setTimeout reject - composition is cleaner and you keep the abort reason. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#practical-patterns]
Reconcile rejections with the Map pattern: add on 'unhandledRejection', delete on 'rejectionHandled', report the residue on shutdown. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#practical-patterns]
Re-bind pool callbacks with AsyncResource.bind(cb) (or AsyncLocalStorage.bind) at enqueue time so the dequeued callback runs in the right request context. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#practical-patterns]

Anti-patterns

Serialized awaits in a loop - for (const x of xs) await f(x) when the calls are independent. That's sequential latency; use await Promise.all(xs.map(f)) (with a concurrency cap for large xs). [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#anti-patterns]
Unbounded Promise.all over a huge array - fires every task at once and exhausts sockets / trips rate limits. Cap in-flight work. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#anti-patterns]
Treating 'uncaughtException' as resume-and-continue - the process is in an undefined state; do sync cleanup, then exit and let a supervisor restart. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#anti-patterns]
process.exit() to "finish" - truncates buffered output and abandons pending work; set process.exitCode and let the loop drain. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#anti-patterns]
Matching on err.message - breaks across versions and locales; match on err.code. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#anti-patterns]
Swallowing errors (catch {}), or catching without re-throwing the unknown ones - you lose the failure and the cause chain. Narrow on code, re-throw the rest. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#anti-patterns]
AsyncLocalStorage.enterWith() in shared/event-handler code - leaks the store into unrelated later callbacks; use run(). [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#anti-patterns]
Building a context system on raw async_hooks.createHook - it's experimental and error-prone (a throw in a hook is fatal); use AsyncLocalStorage / AsyncResource. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#anti-patterns]

Troubleshooting

fetch/op doesn't actually stop on abort → you logged 'abort' but didn't pass signal into the call's options, or you created a new controller per retry; pass the same signal down and check signal.aborted. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#troubleshooting]
Caught error but instanceof MyError is false → you compared types across a module boundary or the error was re-wrapped; branch on err.code (and inspect err.cause) instead. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#troubleshooting]
Promise.any "fails" unexpectedly → it rejects with an AggregateError only when all inputs reject; read err.errors. If you wanted first-settled, use race. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#troubleshooting]
Process crashes despite an uncaughtExceptionMonitor listener → monitor does not suppress the crash; install an 'uncaughtException' handler (that then exits) if you must intercept, but don't resume. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#troubleshooting]
als.getStore() is undefined downstream → context was lost at a native/pool/emitter boundary; wrap the callback with AsyncResource.bind / AsyncLocalStorage.bind, or promisify a callback API so the store propagates. Don't paper over it with enterWith(). [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#troubleshooting]
Unhandled rejection silently ignored → check --unhandled-rejections; if set to warn/none it won't crash. Default (throw) surfaces it. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#troubleshooting]

References

Node.js - Globals: AbortController / AbortSignal (abort, reason, throwIfAborted, timeout(), any()): https://nodejs.org/api/globals.html [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#references]
Node.js - Errors: Error.cause, error.code convention (match code not message), AggregateError, ABORT_ERR/system codes: https://nodejs.org/api/errors.html [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#references]
Node.js - Process: uncaughtException / unhandledRejection / rejectionHandled / uncaughtExceptionMonitor, process.exitCode vs process.exit(), 'exit': https://nodejs.org/api/process.html [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#references]
Node.js - CLI: --unhandled-rejections=<throw|strict|warn|warn-with-error-code|none>: https://nodejs.org/api/cli.html [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#references]
Node.js - util.promisify / util.callbackify / util.promisify.custom: https://nodejs.org/api/util.html [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#references]
Node.js - Async context tracking: AsyncLocalStorage (run/getStore/enterWith/exit/snapshot/bind) and AsyncResource: https://nodejs.org/api/async_context.html [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#references]
Node.js - async_hooks (createHook init/before/after/destroy, executionAsyncId/triggerAsyncId; experimental, prefer AsyncLocalStorage): https://nodejs.org/api/async_hooks.html [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#references]
MDN - Promise.all / Promise.allSettled / Promise.any (AggregateError) / Promise.race: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-async-patterns-error-context/#references]

Where this helps

Wiring a request-scoped id or trace span through a Node service so any nested async call can read it without threading an extra parameter through every function signature, using AsyncLocalStorage.run(). [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Building a cancellable operation, such as an HTTP call, a file read, or a long-running job, that needs to unwind cleanly when a client disconnects or a deadline passes, using AbortSignal.any() to OR a user-cancel and a timeout together. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Debugging a promise-based batch operation that's either too slow from serialized awaits in a loop, or exhausting sockets from an unbounded Promise.all over a huge array. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Deciding how a process should react to an uncaughtException or an unhandled rejection, distinguishing log-and-let-a-supervisor-restart from the anti-pattern of trying to resume. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Project ideas

Build a request-context middleware using AsyncLocalStorage.run() that threads a request id and trace span through every downstream async call, replacing manual parameter-threading. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Build a cancellable fetch wrapper that composes AbortSignal.any([userSignal, AbortSignal.timeout(ms)]) so one call site gets both a deadline and a user-cancel path, forwarding the same signal into every downstream fetch, timer, or fs call. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Build a concurrency-capped batch runner, a small worker-pool pulling from a shared iterator or a wrapper around p-limit, to replace an unbounded Promise.all(items.map(fn)) that's tripping rate limits. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Build an unhandled-rejection reconciler that tracks pending rejections in a Map, adding on unhandledRejection and deleting on rejectionHandled, and reports the residue at shutdown instead of letting them vanish silently. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Common mistakes

Writing a for-of loop that awaits each call in sequence when the calls are independent: this serializes latency that Promise.all, with a concurrency cap, would run in parallel. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Matching on err.message instead of err.code: Node's docs are explicit that message text can change in any version while code only changes across major versions. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Calling process.exit() to finish a script: it terminates synchronously, can truncate buffered stdout/stderr, and abandons any pending async work, where process.exitCode plus letting the loop drain naturally is the correct pattern. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Building a context-propagation system directly on async_hooks.createHook instead of AsyncLocalStorage: the raw hook API is experimental, low-level, and a throw inside a hook is fatal. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Known issues

AsyncLocalStorage.enterWith() sets the store for the rest of the current synchronous execution with no automatic exit, which the docs warn leaks easily; for example, a second event-handler on the same emitter can inherit a store it shouldn't have. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
AbortSignal.timeout(ms) does not keep the event loop alive by itself, so it won't prevent a process from exiting even while the timeout is still pending. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Context tracked by AsyncLocalStorage can be lost at a boundary the mechanism can't see, such as a callback queued by native or third-party code, an object-pool worker, or a long-lived emitter, and needs an explicit AsyncResource.bind() to restore it. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Treating uncaughtExceptionMonitor as a way to intercept and suppress a crash is a mistake baked into the API itself: the monitor observes the exception without changing whether the process crashes. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Children

Cancellation with AbortController / AbortSignal (signal, reason, 'abort', throwIfAborted) (frontier)
Composing signals — AbortSignal.timeout() and AbortSignal.any() (frontier)
Structured errors — Error.cause, AggregateError, custom error classes (frontier)
The error.code convention — match on code, never message (frontier)
Process-level failure — unhandledRejection / uncaughtException / rejectionHandled and exit semantics (frontier)
Promise concurrency — all vs allSettled vs any vs race + concurrency limiting (frontier)
Context propagation — AsyncLocalStorage (+ async_hooks / AsyncResource) (frontier)

Frontier under this node: Cancellation with AbortController / AbortSignal (signal, reason, 'abort', throwIfAborted), Composing signals — AbortSignal.timeout() and AbortSignal.any(), Context propagation — AsyncLocalStorage (+ async_hooks / AsyncResource), Process-level failure — unhandledRejection / uncaughtException / rejectionHandled and exit semantics, Promise concurrency — all vs allSettled vs any vs race + concurrency limiting, Structured errors — Error.cause, AggregateError, custom error classes, The error.code convention — match on code, never message

← the whole tree · 3D view· how to read this page