Session Proposal: NodeJS Asynchronous Scheduling

[ronag]

Proposal

Topic of the session

Existing pitfalls in NodeJS asynchronous scheduling and patterns.

• Inconsistent behavior of nextTick and queueMicrotask (Inconsistent behavior of nextTick and queueMicrotask nodejs/node#51156).
• Incompatibility between asynchronous patterns such as asynchronous events/callbacks and promises (process: add deferTick nodejs/node#51471).

Type of the session

• Collaborate
• Workshop
• Talk

Estimated duration of the session

Date and Time of the session

Level

• Beginner
• Intermediate
• Advanced

Pre-requisite knowledge

Describe the session

Session facilitator(s), Github handle(s) and timezone(s)

Meeting notes and Virtual Meeting Link

Follow-up / Set-up sessions (if any)

Additional context (optional)

---

[ronag]

Refs: nodejs/node#51471
Refs: nodejs/node#51114
Refs: nodejs/node#51070
Refs: nodejs/node#51156
Refs: nodejs/node#51280
Refs: nodejs/undici#2497

[ronag]

@mcollina

[benjamingr]

Would love to attend this remotely or discuss offline

[ronag]

Might be also relevant to make sure that the docs are correct:

https://www.builder.io/blog/visual-guide-to-nodejs-event-loop
https://nodejs.org/en/learn/asynchronous-work/understanding-processnexttick

[ronag]

Example of problem to discuss.

import { EventEmitter } from 'events'

// Unhandled exception
setImmediate(async () => {
  const e = await new Promise(resolve => {
    const e = new EventEmitter()
    resolve(e)
    process.nextTick(() => {
      e.emit('error', new Error('nextTick'))
    })
  })
  e.on('error', () => {})
})

// Unhandled exception
setImmediate(async () => {
  const e = await new Promise(resolve => {
    const e = new EventEmitter()
    resolve(e)
    queueMicrotask(() => {
      e.emit('error', new Error('queueMicrotask'))
    })
  })
  e.on('error', () => {})
})

// OK, but slow
setImmediate(async () => {
  const e = await new Promise(resolve => {
    const e = new EventEmitter()
    resolve(e)
    setImmediate(() => {
      e.emit('error', new Error('setImmediate'))
    })
  })
  e.on('error', () => {})
})

Please don't get hung up the 'error' event. This is a problem with other events as well. In many cases they can be worse, e.g. a similar example with waiting for a 'ready' event would deadlock instead of crash.

[benjamingr]

I'm wondering if it's possible to solve generically by adding the capability to emit an event after someone is listening to it to the abstraction itself - e.g. by providing a helper to defer emitting an event up to setImmediate if there are no existing listeners for it.

This is similar to what we do for promises at the moment with unhanadled rejection detection.