Module async_hooks 

Node async_hooks module — honest minimal implementation.

node-js has no per-async-resource id tracking and no async-context propagation, so most of this module is a deliberate, documented no-op whose only job is to let code that defensively imports async_hooks load and run without crashing:

• executionAsyncId() returns a fixed 1, triggerAsyncId() returns 0. These are NOT real resource ids — there is no async-resource graph.
• createHook({ init, before, after, destroy }) returns a hook object with chainable enable()/disable(). The registered callbacks are stored nowhere and NEVER FIRE — node-js does not instrument async resource lifetimes. This is intentional; do not treat it as a gap to “fill” by faking hook invocations.

What IS real is AsyncLocalStorage for the SYNCHRONOUS case: run(store, cb) makes getStore() return store for the duration of cb (and restores the previous store afterwards), and enterWith(store) sets the current store for subsequent synchronous getStore() calls. Because there is no async-context propagation, a store set with enterWith (or visible inside run) does NOT automatically follow into setTimeout/Promise callbacks — cross-async propagation is not modeled. Within straight-line synchronous code the store is correct.

Instances are @@native-tagged objects (AsyncLocalStorage / AsyncHook) dispatched through instance_call; the parent wires construct, native_tag, instance_has_method, and instance_call (see the report).

Constants

ALS_METHODS

Instance method names by native tag — for the parent’s instance_has_method so a method read (als.run.bind(...)) resolves before it is invoked.

HOOK_METHODS

METHODS

Module-level callable members.

Functions

call

construct

Construct a stdlib class instance (new AsyncLocalStorage()). None for any other name so the parent’s construct can fall through.

instance_call

Dispatch a method on a native async_hooks instance.