async_hooks is raised on Step in debugging into async/await function and on leaving await function

[pubmikeb]

• Version: v16.0.0-nightly2020110785b42af439
• Platform: Windows 10 x64 20H2

What steps will reproduce the bug?

I've paid attention that now when I click on Step Into on async/await function debugger goes to the Node.js internal async_hooks file instead of jumping to the wanted async/await function (screencast: Video_2020-11-07_123421.zip).

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

Currently the debugging experience of async/await functions is much more problematic, I always have to firstly go away from async_hooks to reach the wanted function, which I actually need to debug. The same things happens when I leave the async/await function, I'm firstly forwarded to async_hooks and only then to the initial function, where I've started my debugging.

What is the expected behavior?

When I click on Step Into, I expect to be forwarded to the function itself, not to the async_hooks.

What do you see instead?

I always have to firstly go away from async_hooks to reach the wanted function, which I actually need to debug.

Additional information

I've assumed it is an issue of the IDEA/WebStorm, but the JetBrains Team confirms such behavior on VSCode as well.
Please check if it is a regression.

Sample IDEA/WebStrom project (WEB-48157.zip). Please, put the breakpoint on the line #23 (app.js) and try to debug the await tst("Boo"); function. Are you also redirected to async_hooks firstly?

[Jamesernator]

Stepping in all scripts is just how v8's debugger works, it sounds like you can tell IDEA to skip stepping into some files: https://www.jetbrains.com/help/idea/settings-debugger-stepping.html#aa57f

[pubmikeb]

The key thing is that I started to observe such behavior just since v16.0.0-nightly2020110785b42af439, previously I've never landed to async_hooks during the debugging (at function entrance and upon the leaving the function). That's why I've raised a ticket.

[connor4312]

I received a report of this in the VS Code debugger and reproduced on 15.8.0 (microsoft/vscode#115670). Although we set blackbox patterns for files including ^node:internal\/async_hooks$, the debugger pauses there regardless

Here's a complete log file: https://memes.peet.io/img/vscode-debugadapter-f1a21bb1.json.gz. You can open it in our tool and enter async_hooks on the grep box on the right side to see the relevant traffic to and from the debugger.

[arciisine]

I've just run into this issue as well, and no amount of configuration seems to affect it. I've seen #15464, which seems to indicate a similar problem was fixed. This seems to have been a regression somwhere in the 15.x line.

[bodqhrohro]

I experience the same on v12.19.0 in Chromium debugger. And even stepping out of async_hooks does not help: the execution continues to the caller, skipping the awaited function entirely. And if I keep piling through lots of internal functions, I just get lost and have to go through lots of other hooks not related to the inspected one, but have a chance to finally run into it if being patient and observant enough.

[fabioespinosa]

For those struggling with the VS code debugger, this config helped (along with the skipFiles):

"runtimeVersion": "14.9.0",

[breautek]

I experience the same on v12.19.0 in Chromium debugger. And even stepping out of async_hooks does not help: the execution continues to the caller, skipping the awaited function entirely. And if I keep piling through lots of internal functions, I just get lost and have to go through lots of other hooks not related to the inspected one, but have a chance to finally run into it if being patient and observant enough.

Encountered the same experiences on v12.22.1 and also tested the latest v.16.4.0 release. I believe it only occurs on functions using the async / await keywords. I've migrated a lot of code to use this for readability over the last year but now I need to actually debug a complicated problem where using the inspector is necessary, and it's nearly impossible to walk through the code. I basically can't use step into and instead have to manually go to the function to add a breakpoint so that I can "Continue" to the breakpoint instead of using the Step commands so that I can skip over internal/async_hooks. Incredibly tedious...

[jackhollowaypersonal]

Is there still no workaround for this? I cannot use 14.9.0 without Rosetta as I'm on Apple Silicon.

[pubmikeb]

The problem (WEB-48157) has been fixed for IntelliJ IDEA starting 2021.2 EAP (212.4535.15 build).

[jackhollowaypersonal]

The problem (WEB-48157) has been fixed for IntelliJ IDEA starting 2021.2 EAP (212.4535.15 build).

Just waiting on VSCode fix now then I take it?

[breautek]

The problem (WEB-48157) has been fixed for IntelliJ IDEA starting 2021.2 EAP (212.4535.15 build).

I wouldn't really call this a fix, just a workaround being implemented by that editor.

Based this thread this issue occurs with:

• IntelliJ (with a workaround being implemented in an upcoming release)
• VSCode
• Google Chrome DevTools

Based on previous comment:

Stepping in all scripts is just how v8's debugger works

It sounds like the real issue is with Node's decision of using these internal JS code being injected/used.

Related: #11893

[connor4312]

I've also implemented a (probably similar) workaround for VS Code in microsoft/vscode-js-debug#1085

[lacmuch]

I have the same problem with Chrome Devtools v98.0.4758.102 & NodeJS v17.6.0
Can't ignore node:internal/async_hooks
I'm soooo saaad :(

[joshuakb2]

I have this issue with the chrome debugger. It's difficult to step through async/await code. I have to set temporary breakpoints manually to make sure I arrive where I'm trying to go.

[magicdawn]

2024 chrome v124, still steps into async_hooks with manual ignore settings

[connor4312]

@magicdawn that's #50058

[StefanStojanovic]

This issue was opened on an old, no longer supported version of Node.js. Also, there is another issue opened for this same problem.

Sample IDEA/WebStrom project (WEB-48157.zip). Please, put the breakpoint on the line #23 (app.js) and try to debug the await tst("Boo"); function. Are you also redirected to async_hooks firstly?

I tested with this in VS Code and latest version of Node.js and wasn't redirected to async_hook. Unless there are some objections over the weekend, I will close this issue on Monday.

[breautek]

I tested with this in VS Code and latest version of Node.js and wasn't redirected to async_hook. Unless there are some objections over the weekend, I will close this issue on Monday.

The issue still occurs on Node v22.5.1. Maybe WebStorm or VS Code does something to work around the issue but it reproduces if you use the simple chrome web inspector.

Reproduction code:

// test.js

async function testFunction() {
    return Promise.resolve();
};

(async () => {
    await testFunction(); // Breakpoint on this line
})();

My reproduction steps:

1. Launch node via node --inspect-brk test.js
2. Open the inspector by going to chrome://inspect and Inspect the node process.
3. Set breakpoint on await testFunction(); line
4. Continue to breakpoint hit.
5. Step into the testFunction

The debugger steps into node:internal/async_hooks at this point.

NodeJS 22.5.1 Environment:

Screencast.from.2024-07-19.11-22-16.webm

The V8 Engine found in the Chrome browser does not exhibit the same behaviour:

Screencast.from.2024-07-19.11-26-26.webm

So I think that shows that the issue is specific to NodeJS runtimes (likely due to these internal/ js modules)

[StefanStojanovic]

@breautek thanks for the detailed description and reproduction steps. The reason I wanted to close this was that WebStorm and VS Code already fix this (I wasn't aware of the chrome web inspector at that time).

Even with the issue still being active in Chrome, I'd still propose closing this, since there is another issue digging much deeper into this topic and it already references this one in it's last comment.

[arsinclair]

@StefanStojanovic this issue has 27 upvotes and the other one only 1. If one should be closed, I'd say it's that one: even if it dives deeper into the subject, that information should be just copied over here.

That issue was created 3 years before this one, and with only one upvote it seems that this issue is much better formulated if anyone who searches for the problem lands here.

[breautek]

@breautek thanks for the detailed description and reproduction steps. The reason I wanted to close this was that WebStorm and VS Code already fix this (I wasn't aware of the chrome web inspector at that time).

Even with the issue still being active in Chrome, I'd still propose closing this, since there is another issue digging much deeper into this topic and it already references this one in it's last comment.

#11893 does seem to document the root issue and it seems the blackbox idea that's been passed around in that thread will likely solve this issue as well. So I don't personally have any objections of this issue being closed in favour of a ticket that addresses the issue from a broad sense. It makes sense to me.

The reason I wanted to close this was that WebStorm and VS Code

In my opinion the fixes found within VSCode/WebStorm are a workarounds of odd/"buggy" (for a lack of a better term) behaviour of NodeJS. I'm sure there are use cases for stepping into node internals, but those use cases are likely limited to NodeJS contributors developing NodeJS. Most users trying to debug their applications likely aren't interested in what the internals is doing. But it sounds like we are still on the same page if #11893 will continue progress on solving the problem.

[StefanStojanovic]

I agree with all that you said. I'll close the issue now, in favor of the other one. If needed we can reopen this one at any time too.