Different async_hooks behavior in Node 10

[Conduitry]

• Version: v10.0.0
• Platform: Linux, Windows 10 WSL

Running the following code

const async_hooks = require("async_hooks");
const fs = require("fs");

async_hooks
  .createHook({
    init: (asyncId, type, triggerAsyncId, resource) => {
      fs.writeSync(1, `${triggerAsyncId} => ${asyncId}\n`);
    }
  })
  .enable();

async function main() {
  console.log("hello");
  await null;
  console.log("hello");
}

main();

on Node 9 gives the output

1 => 6
hello
1 => 7
6 => 8
8 => 9
hello
9 => 10

while on Node 10 it gives

1 => 6
hello
1 => 7
1 => 8
hello
1 => 9

That is, on Node 10, the triggerAsyncId is always 1, and I am unable to track which contexts follow from which other contexts.

Is one of these unexpected behavior? If the change is a known (undocumented?) new behavior, is there any way with Node 10 to achieve what I was doing under previous versions?

[apapirovski]

I don't really see any changes on our end that could've caused this. I think it might be due to changes in V8.

ping @nodejs/v8 — did anything change about PromiseHooks or Promises that could be causing this? I see there's one less Promise now so it does seem like at least some stuff changed.

/cc @nodejs/async_hooks

[hashseed]

Can someone bisect to verify that this was caused by a V8 upgrade? /cc @bmeurer

[apapirovski]

Unfortunately don't have time do git bisect given the time it takes to recompile when V8 changes but as far as I can tell on v9.x all the promises (3 of them) are related (that is, each subsequent one seems to be a child of the previous one). On v10.0.0, they're both (only 2! now) independent.

Oh and neither version seems to trigger before or after hooks in this example.

(For all I know this new behaviour could be more correct...)

[bmeurer]

That's on purpose. We optimize away some promise allocations.

[apapirovski]

@bmeurer Are you saying the number of promises is intentional or the fact that we're no longer tracking the nested promises as children like we used to? This seems to complicate async hooks behaviour in relation to async/await.

(Although I don't really know if that's true... the new log might be slightly more accurate if less helpful in terms of tracking.)

[bmeurer]

@apapirovski The fundamental problem is that there's no formal semantics for PromiseHooks. So we don't even know what's right or wrong. I'm not sure about the relation chain here either, as I don't now what's right and what's wrong.

[Jeff-Lewis]

@AndreasMadsen any thoughts on this?

[apapirovski]

Well, this will certainly need to get addressed somehow... but I don't think we can do it without changes in V8. We don't really have the required context information to patch around this in any way.

[hashseed]

How about specifying requirements and adding comprehensive tests first? The turnaround time for V8 changes to end up in Node is pretty long. Fixing this kind of issues one by one on an ad hoc basis will not work.

[benjamingr]

How about we gather a bunch of consumers of async_hooks and promises and work out use cases of what we need to accomplish with them before we recommend any changes?