Fix unhandled promise rejection tracker, again

[saghul]

Mark a rejected promise as handled if we are passing it as as a resolution up a promise chain.

[saghul]

@ChALkeR mind taking a look?

[ChALkeR]

#1038 (comment) now works

#1038 (comment) doesn't

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

[ChALkeR]

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

[saghul]

Actually a simpler one:

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

[saghul]

Back to the drawing board :-)

[ChALkeR]

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)

[ChALkeR]

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)

[saghul]

You're right...

[saghul]

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

[ChALkeR]

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

Changed the approach.

[saghul]

@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.

[saghul]

@ChALkeR do your worst :-)

[bnoordhuis]

Checking for specific callbacks seems a little fragile but I don't have a better suggestion.