process.nextTick vs promise microtasks, and starvation

The chair runs the meeting by one rule about two lists.

In the council chamber	In Node
when a speaker sits down, the chair first hears every point of order, including ones raised meanwhile	the tick queue drains after each callback (step 2)
then every follow-up question on the list, in sign-up order	the microtask pass, FIFO (step 3)
a point of order raised during questions is heard once the question list is empty	a tick queued in a microtask waits (step 4)
the next agenda item and the public gallery wait until both lists are empty	the loop continues only then (step 6)
a member who raises a new point of order in every point of order stalls the meeting	recursive nextTick starves everything (step 7)
the chair's opening address is given during question time	ES-module top level (step 10)

In real terms: after every callback Node empties two queues in turn, ticks first, and the loop waits for both.

Breaks down when: a real chair can rule a point of order out of order. Node has no cap: the docs warn that recursive nextTick can create an infinite loop.

Contrasting case: the browser has no tick queue. There, promise callbacks and queueMicrotask share the only microtask queue, the prerequisite's model.

4.1 ExamHall: the proctors' dashboard froze

EXH-1330: the proctor console server dedupes a backlog of candidate events in batches, inside a socket callback. Each batch re-scheduled the next with process.nextTick. A 50 ms timer pushes the proctors' live dashboard; while the backlog lasted, it never fired, and the dashboard froze. MR !1530 re-schedules with setImmediate.

const step = () => { dedupeBatch(); if (more()) reschedule(step); };   // 100 batches, 10 ms of CPU each
setInterval(pushDashboard, 50);                                        // the proctors' live view

4.1 process.nextTick (as shipped)   batches 100/100 · dashboard pushes during dedupe: 0
4.1 setImmediate (MR !1530)         batches 100/100 · dashboard pushes during dedupe: at least 1

With nextTick the tick queue never empties, so the loop never reaches its timers (step 7). Why setImmediate lets the loop move on is node-event-loop-phases step 7. The work and its total CPU are unchanged; only who waits changes.

4.2 Where the entry module type matters (fixtures/entry.cjs, fixtures/entry.mjs)

The same three lines, then, nextTick, queueMicrotask, run at the top level and again inside a setImmediate callback, in a CommonJS file and in an ES module:

4.2 CommonJS  top level                    nextTick · then · microtask
4.2 CommonJS  inside a setImmediate        nextTick · then · microtask
4.2 ES module top level                    then · microtask · nextTick
4.2 ES module inside a setImmediate        nextTick · then · microtask

Only the ES module's top level differs: it is already inside a microtask pass, so the tick waits (steps 4, 10). Inside a callback both agree (step 11). A test that pins an order at the top level of an .mjs file can pass while the same code, run from a request handler, behaves differently.