@ChALkeR mind taking a look?

#1038 (comment) now works

#1038 (comment) doesn't

assert.rejects also doesn't work due to #1038 (comment)

Simplified testcase:

const promise = Promise.reject('reject')
const error = await Promise.resolve().then(() => promise).catch(e => e)
console.log('Got this error:', error)

This still crashes the process

Actually a simpler one:

const promise = Promise.reject('reject')
print(promise)

Back to the drawing board :-)

Actually a simpler one:

const promise = Promise.reject('reject')
print(promise)

Node.js disagrees on that and treats that as unhandled (unlike the other examples above)

Latest commit doesn't catch this anymore:

async function foo() {
  throw new Error('failed')
}

foo()

const setTimeout = globalThis.setTimeout || os.setTimeout
setTimeout(() => console.log('done'), 1000)

You're right...

Removed the latest commit. I need to see how to tell those 2 cases appart.

That depends on the event loop

In Node.js:

• Promises with .catch attached in Promise.resolve().then are not treated as unhandled
• Promises with .catch attached in process.nextTick are not treated as unhandled
• Promises with .catch attached in setTimeout including setTimeout(,0, or setImmediate are treated as unhandled

@bnoordhuis PTAL again, I changed the approach.

The way it currently works Promise.reject(...) would enqueue a tracker job always, and if another promise adds a then / catch to handle it, it will be too late because jobs are executed FIFO of course. So I added some logic in the unhandled rejection tracker to re-enqueue the job if it sees other stuff going on, this way, delaying the execution means there is a chance to handle the rejections.

@ChALkeR do your worst :-)