Webstorm debugger for node.js doesn't connect for executed node.js process

I'm try to debug my js code from node.

 

For example, I

  1. make a default node.js project from webstorm templates (express app).
  2. press debug button (or Run -> Debug at top bar)
  3. presetted debugger for that project started
  4. At debugger window I see how node process started and waiting while any debugger connect for it
  5. And that's all. Nothing happens.
  6. But if I use embedded node.js debugger at chrome, it connected to the 62102 port and I see message how debugger connected.

What I'm doing wrong? As I see at guide here: https://www.jetbrains.com/help/webstorm/running-and-debugging-node-js.html, webstorm debugger must automatically connect to node process.

My webstorm data:

WebStorm 2018.1.5
Build #WS-181.5281.31, built on June 14, 2018

JRE: 1.8.0_152-release-1136-b39 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.12.6

32 comments
Comment actions Permalink

Please can you explain what makes you think that the debugger doesn't connect? Lack of `Debugger attached` message? You shouldn't care about it, debugger is attached even though the message is not there.

Did you try setting breakpoints? Also, I'd suggest enabling After launch in Browser/Live Edit tab of your run configuration to the application loaded in browser once the server is started

 

0
Comment actions Permalink

Yes, I'm sure that webstorm debugger is not connected.

When I turn debug at express app example and after that open http://localhost:3000 at my browser, I don't see anything, because node doesn't listen 3000 port, because that started with --inspect-brk param and waiting for debugger. And if i connect to node process with chrome debugger, and start execution everything is ok.

0
Comment actions Permalink

weird... you are using the default configuration that definitely works.

Can you recreate the issue and provide your idea.log (https://intellij-support.jetbrains.com/hc/en-us/articles/207241085-Locating-IDE-log-files) and screencast that shows your steps?

0
Comment actions Permalink

I cannot believe the level of incompetence of JetBrains when it comes to resolving such issue. Do you guys even perform QA? this has been happening to me since and whenever it occurs I just had to restart webstorm and it works again. I cannot believe we fail at replicating this at all.

anyway, here is my reporduction step
1. go to chrome chrome://inspect/#extensions
2. inspect "JetBrains IDE Support"
3. error is "Cannort create item with duplicate id"

This occurs I believe when you try to restart the debug mode with several breakpoints in place early on while also not stopping then clicking the debug but rather just clicking the debug icon while one is already running. This will occur randomly on my end but is the common way of replicating it on this stupid IDE. not worth the money if it takes more than a year for this to fix on their end TBH!

Environment are as follows:

{"name":"WebStorm 2019.1.3","productName":"WebStorm","baselineVersion":191,"buildNumber":"191.7479.14"}

NodeJS Ver: 10.16.0 (but also happens to 8 and 6)

-2
Comment actions Permalink

Are there any updates on this issue? This happens to me pretty often and I don't know what exactly fixes it, I just have to restart almost everything for it to start working. The same steps, simple node.js app, the whole process gets stuck at:

 

Debugger listening on ws://127.0.0.1:61127/3916f003-4f92-4bb3-bc47-16073a377fc6
For help, see: https://nodejs.org/en/docs/inspector
0
Comment actions Permalink

Must be https://youtrack.jetbrains.com/issue/WEB-40496; please try disabling js.debugger.use.node.options key in Registry (Help | Find action, type Registry to locate it) - does it make things any better?

4
Comment actions Permalink

Works for now, will report later on. Thanks for a quick answer, Elena!

0
Comment actions Permalink

I believe, webstorm needs a bit of time (milliseconds), to successfully connect to the running remote debugger host of a running remote application.

Try working with a timeout:
setTimeout(function () {
console.log ('Timeout!'); // Breakpoint here
}, 1000);

Then the webstorm debugger client should (< 1000ms) successfully connect/attach himself to the running remote debugger process, which was started by --inspect.

Otherwise, I have tested --inspect-brk, then "Break before user code starts" makes it possible, to recognize where to break further execution, by your breakpoints.

https://nodejs.org/en/docs/guides/debugging-getting-started/#command-line-options

If nothing of them helps, only the listening remote debugging port could already be in use, or the debugger host address is not reachable by the debugger client of webstorm.

If the debugger host address and port is reachable, and debugging really doesn't work like described here, only a miss configuration of webstorm`s debug configuration (for example no "Reconnect automatically" checked) could be the reason.

Sometimes, obviously/surely by an internal interval for reconnecting from webstorm`s debugger client to the running remote debugger host, it seems, that its only working randomly, if the connection to the debugger host already works, before the remote process executes the script and/or can recognize any breakpoints to break execution.

Thats obviously all about it.

 
 

 

 

0
Comment actions Permalink

Running into this issue today.  Going to the Registry in WebStorm, there is no js.debugger.node.use.inspect key in that registry.  So 2.5 years from first report and this issue is still not resolved.

UPDATE:  I restarted WebStorm and the problem went away - now the debugger attaches.  But restarting WebStorm is not an acceptable solution.

2
Comment actions Permalink

Eric Hill

WebStorm -> Help -> Find Action... -> type "Registry..." -> js.debugger.use.node.options

But this config does not work for me.

0
Comment actions Permalink

@kook ob  please could you elaborate on this? what issue have you faced namely, what does your run configuration look like, what IDE version do you work with?

0
Comment actions Permalink

Elena Pogorelova

Hello, I develop a project with eggjs framework. 
And create a simple method like this:

class HomeController extends Controller {
async index() {
const { ctx } = this;
ctx.logger.info('IDE bug test'); //debug breakpoint or other line
ctx.body = 'hi, eggjs';
}
}

When I first start the project(with debugger mode). Sometimes can debugger attached.

logger demo:
Debugger attached.
Use $NODE_DEBUG_OPTION:
Debugger listening on ws://127.0.0.1:9229/a58e92e9-e394-40b6-b3a2-c2d4877a9b71
For help, see: https://nodejs.org/en/docs/inspector
Debugger listening on ws://127.0.0.1:61216/fac1896d-64b5-41de-84e1-72a676a4ea9b
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.

But when I change the code anywhere, the IDE will reload the project and can't debugger attached not anymore.
like change `ctx.logger.info('IDE bug test');`  to `ctx.logger.info('IDE new test'); `
Then the project can not debugger any more.

You can check the eggjs issue from here: https://github.com/eggjs/egg/issues/4095
But this issue has not solved for many years. The author replied that this was the WebStrom problem.
I try many WebStrom version, like: 2019.*,2020.1, 2020.2, 2020.3,all newer than 2019 version has this problem.

This bug has been suffering for years and it would be great if it could be resolved as soon as possible.

0
Comment actions Permalink

Works fine for me

My steps:

- created a debug config like:

 

- added a breakpoint to line

ctx.logger.info('IDE bug test');

- started egg with

egg-bin debug

- reloaded the page in browser - breakpoint is hit; resume

- change the code, Save

- refreshed the browser once again - breakpoint is hit:

0
Comment actions Permalink

I try the step like you, but it still does not work for me.

What's your WebStrom version?

Are your `egg-bin debug` start in the terminal?

Chrome:  http://localhost:7001/

the breakpoint  can't hit.

---------------------------------------------------

A normal startup configuration looks like this

 

This startup mode works fine in the WebStrom 2018.  (not with terminal)

 

0
Comment actions Permalink

"Works on my machine." - Elena

For WebStorm on Mac, it's a problem that comes and goes.  I've just moved to Mac from Windows, but when I asked colleagues about this problem, another colleague who's been on Mac awhile said, yes, this problem comes and goes.  Things will work fine for awhile, and then suddenly they stop working, so he restarts WebStorm and the problem goes away.  Until it comes back.  I'd been using WebStorm on Windows for several years and never saw the problem.  We are using nvm to install node.js, which I doubt matters but one never knows.

Thanks,

Eric

0
Comment actions Permalink

@kook ob I'm using the most recent version, 2020.2.3.1; can't comment on v 2018, sorry

0
Comment actions Permalink

@Elena Pogorelova I know, what I mean is that this startup method is works fine in the 2018 version, and will not work in any new version after 2019.

0
Comment actions Permalink

Debugging with Attach to Node.js/Chrome run configuration works fine for me; and, as far as I can check from the info available on the web, it's the recommended approach, see https://developpaper.com/vscode-debugging-egg-js/, for example

0
Comment actions Permalink

@Elena Pogorelova But I do it as you do(Attach to Node.js/Chrome), it still doesn't work for me. Whether it need to install the Chrome extension?

 

0
Comment actions Permalink

No, you don't need any extensions to make this work; it just works for me (in 2020.3.x)

0
Comment actions Permalink

Debugger failed to attach again today, requiring restart (WebStorm/Mac).

 

0
Comment actions Permalink

Happens to me for 2 days now. Not the first time, certainly not the last. Restart webstorm/mac does not solve the issue.

Step to reproduce:

- Create a file

- Write `console.log('damns you webstorm debugger');``

- Right click -> debug file.js

Works if I click "Run file.js"

Weird enough, it happens only on one project

I've done that The debugger works as expected when launch through "right-click debug file.js". In the other hand, the debugger does not stop on breaking point when launch a much complexe code through shortcut in package.json

Closer to find a solution. Changing my node version fix the debugger (we are using node 8.9.0, I know we shouldn't)

0
Comment actions Permalink

@Baptiste Garcin    Node.js version you are using (v.8.9.4) is quite old, it is out of maintenance mode since 2019 according to https://github.com/nodejs/Release.. Please see https://www.jetbrains.com/help/webstorm/supported-node-js-versions.html for the list of interpreter version that are currently supported by us.

Please consider upgrading to Node 10.x or higher. As it's mentioned in Help, if any regressions or bugs associated with Node.js versions that are not maintained are identified in the current IDE version, they will not be fixed:(

1
Comment actions Permalink

Yes, I just figured it out ! As you may have guessed, I am not in responsible for the version of node, we are using. I will change the interpreter for a 10.X version for development and cross my finger it does not break the project.

I am now almost sure that the update of Webstorm to 2020.3.2 break the debugger for this very old project explaining why this bug arose this week.

Thanks for you help Elena.

0
Comment actions Permalink

@Baptiste Garcin I have the same problem as you

@Elena Pogorelova As I start mode above, Will be fixed in the new version?

0
Comment actions Permalink

>Will be fixed in the new version?

Is it about debugging with Node 8.x? No, it won't be fixed; if upgrading Node is not an option for you, I can only suggest downgrading the IDE

0
Comment actions Permalink

Not Node 8.x, my Node version is: v12.13.1 (other version must be the same problem: debugger for eggjs framework)

 

 
0
Comment actions Permalink

it's not clear what has to be fixed; as I wrote above, the issue is not repeatable on our end (i.e. I can debug eggjs as I wrote in https://intellij-support.jetbrains.com/hc/en-us/community/posts/360000174540/comments/360002686479)

0
Comment actions Permalink

Can you debug project with my this start mode? And you will reappear the bug.

 
0
Comment actions Permalink

As of 2021, I found that this was happening to me intermittently in a nodejs script that was being executed from package.json script definition. It had little overhead and executed almost immediately.

To "fix" I used a delay in my code, and set the breakpoint after the delay.

Now I hit the breakpoint consistently.

function delay(time) {
return new Promise(function(resolve) {
setTimeout(resolve, time)
});
}

await delay(500);

0

Please sign in to leave a comment.