Does process.nextTick starve the event loop poll phase during heavy microtask execution?

Answer to the question

Yes. In Node.js a recursive process.nextTick() chain can keep the event loop from ever leaving the nextTick queue, which effectively blocks the poll phase and prevents I/O and timer callbacks from running.

There is no internal “gas limit” or threshold that automatically yields to the poll phase. The loop will continue to empty the nextTick queue until it is empty, regardless of how many microtasks (Promises) are queued. When process.nextTick is used recursively, the loop never reaches the poll phase, so new I/O events are never processed.

Promises are processed after the nextTick queue, but they share the same starvation risk if they are queued recursively. However, process.nextTick has higher priority and will always be drained first.

Confirmed facts

• Node.js executes the nextTick queue completely before moving to the next event‑loop phase.
• There is no automatic limit; a recursive nextTick can run indefinitely.
• Promises are processed after nextTick but can also block if queued recursively.
• Scheduling a callback with setImmediate() places it in the check phase, which requires the loop to run through poll first.
• Thus setImmediate() guarantees that the poll phase will execute at least once before the queued callback runs.

How to verify this behavior

1. Create a minimal script that recurses with process.nextTick and also starts a setInterval(0) to observe I/O.

   let count = 0;
   function tick() {
     count++;
     if (count < 10) process.nextTick(tick);
   }
   process.nextTick(tick);
   setInterval(() => console.log('tick'), 0);
   

   Run it. You will see the interval callback never fires because the nextTick recursion blocks the poll phase.

2. Replace process.nextTick(tick) with setImmediate(tick) and rerun. The interval will now fire, proving that the poll phase ran.

Missing diagnostic detail

To tailor recommendations for your specific code, could you share whether the recursion depth is bounded or if you’re also queuing large numbers of resolved Promises in the same loop?

Bottom line

In practice, avoid deep or unbounded process.nextTick recursion. Use setImmediate or a small timeout to give the poll phase a chance to run, especially when you need to handle I/O or timers concurrently.