event-loopAnswer last reviewed July 2026

So process.nextTick and promise callbacks can actually starve the event loop. Walk me through how that happens, and what it looks like from the outside when it does.

Knows both microtask-class queues drain to exhaustion, and can tell you which recursion patterns freeze I/O and which ones actually yield

What an AI-prepared candidate might say

So process.nextTick callbacks and promise microtasks both run before the event loop continues to its next phase, and both queues get processed completely before anything else happens. The problem is, if a nextTick callback schedules another nextTick, the new one gets processed in the same batch, so a recursive nextTick loop just runs forever and the event loop never proceeds. No timers fire, no I/O callbacks run. Same thing applies to a promise that keeps chaining onto itself. setImmediate is the safe alternative for recursive scheduling, because immediates get processed once per loop iteration and I/O runs in between. From the outside a starved loop basically looks like a frozen server. Requests time out, CPU is busy, and nothing gets logged. The general advice is keep your microtasks short and use setImmediate for repeating work.

Senior
Locked

The drain-to-exhaustion rule, entries queued mid-drain included, and why recursing with setImmediate is safe when recursing with nextTick livelocks the process.

Unlock the depth
Staff
Locked

How a finite-but-long drain shows up as a production latency spike, the ELU-plus-lag pattern that gives it away, and the one-line yield that fixes chunked loops.

Unlock the depth
Follow-up chain
So process.nextTick and promise callbacks can actually starve the event loop. Walk me through how that happens, and what it looks like from the outside when it does. | NodeBook