This trace follows the actual state transitions behind the companion Async Code Still Runs on an Event Loop. Each step below names its concrete inputs; values illustrate the mechanism and vary across implementations.
Step 1: Submit asynchronous work
An event loop repeatedly selects ready work and runs callbacks or tasks. Asynchronous I/O lets a program arrange for completion to be reported later so the thread can do other work meanwhile. The syntax may look sequential, but the runtime schedules continuations according to its queues and rules.
Step 2: Register its completion
When a Node.js handler starts a network request, the runtime registers work with the operating system or an internal pool. The JavaScript callback runs after completion is reported and scheduled. A long synchronous calculation inside one callback still occupies the event-loop thread and delays unrelated requests.
Step 3: Run other ready callbacks
When I/O completes, the runtime schedules its continuation; synchronous CPU-heavy work inside a callback still occupies the event-loop thread and delays other ready tasks.
Checkpoint: When I/O completes, the runtime schedules its continuation; synchronous CPU-heavy work inside a callback still occupies the event-loop thread and delays other ready tasks. Confirm this state before advancing to Schedule the continuation.
Step 4: Schedule the continuation
Async does not mean parallel, and adding await does not make CPU-heavy work nonblocking. Queue ordering differs across runtimes and task classes. Unhandled rejections, cancellation, and timeouts need explicit policies so stalled work does not linger indefinitely.
Step 5: Send or consume the result
A service has fast network I/O but slow response times whenever it generates a large report. Explain how an event-loop blocker creates that symptom and how you would move or divide the computation.
The trace is done when this check holds: A service has fast network I/O but slow response times whenever it generates a large report. Compare the outcome against the companion article before making a performance claim.
Hardware, runtime, and observability notes
When tracing Trace: Async Code Still Runs on an Event Loop in a live production environment (subsystem: execution, primary layer: runtime), keep the following step-level cost model and diagnostic checklist in mind:
- Step 1 (runtime): Submit asynchronous work — verifies state invariants before advancing the execution pointer.
- Step 2 (runtime): Register its completion — verifies state invariants before advancing the execution pointer.
- Step 3 (runtime): Run other ready callbacks — verifies state invariants before advancing the execution pointer.
- Step 4 (runtime): Schedule the continuation — verifies state invariants before advancing the execution pointer.
- Step 5 (runtime): Send or consume the result — verifies state invariants before advancing the execution pointer.
Every transition across the runtime boundary carries both a direct CPU/memory cost (cache-line fills, descriptor lookups, lock acquisitions, or context switches) and a tail-latency queueing risk under contention. To verify this trace on your own service, capture latency histograms and hardware/kernel counters across each step boundary, compare cold-cache versus warm-cache execution paths, and confirm that error or timeout branches release all acquired descriptors, locks, and buffers cleanly.