Skip to main content

Demo 40

AsyncLocalStorage request context

AsyncLocalStorage can preserve request context across async boundaries.

fully simulatedcurated scenariodoes not execute real code
Short answer

The key output order is r42 -> r42. AsyncLocalStorage keeps per-request metadata available after awaits when used correctly.

Real-world bug this helps solve

A Node callback, timer, I/O task, stream, or worker-pool job runs later than expected. This powers request logging, tracing, tenant IDs, auth context, and observability in modern Node servers.

Common wrong assumption

Passing request IDs manually everywhere or using globals that mix users together.

Fix direction

Separate sync work, microtasks, timers, I/O, check callbacks, and worker-pool work in your mental model.

Fixed code pattern
setImmediate(runAfterIO);
// Avoid long nextTick loops that starve other phases.
Visual proof

The console lane proves the visible order: r42 -> r42. The active line and queues show why source order changed.

How to verify in a real app

Add timestamps around callbacks and inspect Node diagnostics, logs, or profiler output to confirm the runtime phase that is delaying work.

Share
Loading visual timeline...

Related cases

Continue with nearby confusion while the mental model is fresh.

Recommended next

Was this clear?

This stays local for now. It helps you track where the product still needs sharper cases.

Send detail