executionAsyncId() reports parent context ID in new Promise(fn) function

[isaacs]

• Version:
• Platform:
• Subsystem:

What steps will reproduce the bug?

const { executionAsyncId, createHook } = require('async_hooks')

const {writeSync} = require('fs')
const {format} = require('util')
// hacky console.error() that doesn't cause more contexts to be created
const log = (...msg) => writeSync(2, format(...msg) + '\n')

const hook = createHook({})
hook.enable()

log('before promises', executionAsyncId())
new Promise(resolve => {
  log('eid, first promise', executionAsyncId())
  setTimeout(resolve)
}).then(() => new Promise(resolve => {
  log('eid, second promise', executionAsyncId())
}))

How often does it reproduce? Is there a required condition?

Always.

What is the expected behavior?

The executionAsyncId within the Promise function should be that of the Promise itself, rather than the parent context.

before promises 1
eid, first promise {some number greater than 1 and less than 4}
eid, second promise 4

What do you see instead?

before promises 1
eid, first promise 1
eid, second promise 4

Additional information

Possibly related to #26794, not sure.

Note that the Promise constructor callback does report the proper executionAsyncId when the Promise is created in the context of a Promise chain.

[isaacs]

Here's a TAP-emitting test that you can use to comb through these. Note that the "expect" value seems to be the thing that's mistaken in the current node master branch, which is a huge step in the right direction!

https://gist.github.com/isaacs/c8d15def6869ff738c69037155dda2c2

[sajal50]

I think this might be due to the fact that a new Promise()'s fn callback is called synchronously. Therefore, the execution context didn't change.

[sajal50]

With the existing Promise Hooks types, I don't see any information/hooks given out to the embedder as to start and end points of the callback provided to the Promise. I'd be interested too in knowing if this is possible.

[Flarna]

@sajal50 is correct. The function passed to new Promise() is called sync therefore it has the same eId as it is the same async operation. new Promise() creates/inits a new asyncId which should be signaled via the init hook and is that one you should see in the then callback.

In the end this is quite similar then callback based APIs, e.g. in fs.readFile('file', cb)) the eId within fs.readFile is the same as for the caller. fs.readFile creates a new id which is active in the callback.

[isaacs]

Hm. That does make sense. It's a bit weird that the executionAsyncId changes between the throw and the catch there, but anywhere you put that boundary is going to be strange. And since the executionAsyncId refers to the promise itself in the error/rejection handler, that's fine for making async-hook-domains work properly.