Closed pubmikeb closed 5 days ago
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
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.
I received a report of this in the VS Code debugger and reproduced on 15.8.0 (https://github.com/microsoft/vscode/issues/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.
I've just run into this issue as well, and no amount of configuration seems to affect it. I've seen https://github.com/nodejs/node/issues/15464, which seems to indicate a similar problem was fixed. This seems to have been a regression somwhere in the 15.x line.
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 await
ed 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.
For those struggling with the VS code debugger, this config helped (along with the skipFiles):
"runtimeVersion": "14.9.0",
I experience the same on
v12.19.0
in Chromium debugger. And even stepping out ofasync_hooks
does not help: the execution continues to the caller, skipping theawait
ed 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...
Is there still no workaround for this? I cannot use 14.9.0 without Rosetta as I'm on Apple Silicon.
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:
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.
I've also implemented a (probably similar) workaround for VS Code in https://github.com/microsoft/vscode-js-debug/issues/1085
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 :(
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.
2024 chrome v124, still steps into async_hooks with manual ignore settings
@magicdawn that's https://github.com/nodejs/node/issues/50058
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 https://github.com/nodejs/node/pull/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.
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:
node --inspect-brk test.js
chrome://inspect
and Inspect
the node process.await testFunction();
linetestFunction
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)
@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.
@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 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.
https://github.com/nodejs/node/issues/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 https://github.com/nodejs/node/issues/11893 will continue progress on solving the problem.
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.
What steps will reproduce the bug?
I've paid attention that now when I click on
Step Into
onasync
/await
function debugger goes to the Node.js internalasync_hooks
file instead of jumping to the wantedasync
/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 fromasync_hooks
to reach the wanted function, which I actually need to debug. The same things happens when I leave theasync
/await
function, I'm firstly forwarded toasync_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 theasync_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 toasync_hooks
firstly?