The key output order is io done -> immediate -> timeout. After I/O, Node's check phase gives setImmediate a predictable advantage over a new timer.
A Node callback, timer, I/O task, stream, or worker-pool job runs later than expected. This appears in servers, CLIs, file watchers, and test suites that schedule follow-up work after I/O.
Expecting setTimeout(..., 0) to always beat setImmediate.
Separate sync work, microtasks, timers, I/O, check callbacks, and worker-pool work in your mental model.
setImmediate(runAfterIO); // Avoid long nextTick loops that starve other phases.
The console lane proves the visible order: io done -> immediate -> timeout. The active line and queues show why source order changed.
Add timestamps around callbacks and inspect Node diagnostics, logs, or profiler output to confirm the runtime phase that is delaying work.
Related cases
Continue with nearby confusion while the mental model is fresh.
process.nextTick vs Promise
This matters in Node libraries, stream internals, CLIs, and tests that mix nextTick with promises.
EventEmitter listeners are sync
This explains surprising stack traces and error timing in Express apps, streams, queues, and internal event buses.
Stream backpressure
This prevents memory spikes in file uploads, log pipelines, CSV exports, proxies, and Node API gateways.
Was this clear?
This stays local for now. It helps you track where the product still needs sharper cases.