VSCode-Insiders 2020-09-17 update produces error on startup: "We did not find "node" on your path, so can not enable auto-attach in your environment"

[pmsjt]

Version: 1.50.0-insider (user setup)
Commit: 3156f1f
Date: 2020-09-17T17:22:44.035Z
Electron: 9.3.0
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Windows_NT x64 10.0.19042

Steps to Reproduce:

1. Start VSCode-Insiders
2. Observe error popup.

Does this issue occur when all extensions are disabled?: Yes

[connor4312]

You see this popup because you have auto attach turned on and an environment where we can not safely enable it. See here for details: microsoft/vscode-js-debug#708

If you don't use auto attach, you can disable it in your user settings. If you do use it, then make sure Node is accessible on your path 🙂

[pmsjt]

Well, the catch is that this error started showing up when I restarted VSCode to take an update. I did not change any configuration in the meantime.

Any chance this is a, you know, real bug?

[sweettyler]

@pmsjt I think there is > 99% chance this is a bug:

1. This doesn't happen when running the insider version built on 09/16 and it happens when running the version built on 09/17. So it's changes made within these 24 hours that causes the error.

2. This error will gone if you install the nightly version of JavaScript Debugger (ref Alert on launch #106938).

3. if it is caused by what is described in Auto attach will not be enabled if there is a space in the storage path and we cannot verify you're using Node 12 vscode-js-debug#708, I should have seen this error much earlier, instead of just today.

Other than a bug, there is not a logical explanation.

[pmsjt]

@vscode-triage-bot @connor4312

This is a legitimate regression from the last 24h. It needs to be investigated.

Please reopen the issue (if possible). That will save me the trouble of opening a new one.

Edit-add: Now also repro on my Linux box, just after it updated.

[connor4312]

Well, the catch is that this error started showing up when I restarted VSCode to take an update. I did not change any configuration in the meantime.

In this release, we have changed how auto attach works. This previously was not a requirement, but now it is.

This is a legitimate regression from the last 24h. It needs to be investigated.

Is it the case that you have node on your path but it isn't being found? I'm unclear on that. Thanks!

[pmsjt]

Is it the case that you have node on your path but it isn't being found? I'm unclear on that. Thanks!

How can I check for this? All I know is that I have made a default installation of VSCode on a bunch of my machines (Linux and Windows). I don't have any out-of-the-ordinary configuration and, over the course of one day, all of them are producing an error that I have no idea what it means.

Based on internal reports from the WAVE team and also from @sweettyler here, it seems I am not the only one hitting this.

So, what do you need from me to help investigate the problem?

[connor4312]

From what you have provided, I'm not sure there's anything which is not functioning as intended. If you don't use auto attach, then you can turn it off by setting debug.node.autoAttach to disabled in your user settings. If you don't develop with Node.js or aren't sure what auto attach is, then this is my recommended course of action.

If you do use auto attach, you can install Node.js and add it to your PATH such that VS Code can find it.

[pmsjt]

From what you have provided, I'm not sure there's anything which is not functioning as intended. If you don't use auto attach, then you can turn it off by setting debug.node.autoAttach to disabled in your user settings. If you don't develop with Node.js or aren't sure what auto attach is, then this is my recommended course of action.

If you do use auto attach, you can install Node.js and add it to your PATH such that VS Code can find it.

In that case the bug is that the default configuration is one that produces an error. This should be fixed. The default configuration should not cause errors to be raised to the user.

Especially when that is a breaking change / regression.

[connor4312]

Auto attach is disabled by default (though that may change in the future #53640, and if it does we will need to be smarter about that warning). I'm guessing it might have been turned on on one of your machines at some point, and then if you use settings sync got moved over to your other machines as well. Previously auto attach being on would have been mostly invisible, except for the presence of the "auto attach" badge in the status bar (and some cpu usage on windows polling processes)

[pmsjt]

Auto attach is disabled by default (though that may change in the future #53640, and if it does we will need to be smarter about that warning). I'm guessing it might have been turned on on one of your machines at some point, and then if you use settings sync got moved over to your other machines as well. Previously auto attach being on would have been mostly invisible, except for the presence of the "auto attach" badge in the status bar (and some cpu usage on windows polling processes)

I did not enabled it manually. I can share with you my config. There is nothing there related to the node,js debugging. Please investigate why this is being turned on automatically.

[connor4312]

Does the issue reproduce if you launch code via code --user-data-dir /tmp/user-profile in the command line?

I do not think this is being turned on automatically as you describe, since we have lots of users who don't use Node.js and this is the first report of this as an issue.

[pmsjt]

On by default.

Maybe it is the first report because the regression just happened today? This does not happen with yesterday's build, as it was already mentioned by me and by @sweettyler

[gusbemacbe]

Even if auto-attach comes disabled, I have still this same problem. Every time I open the app, I always receive the pop-up. I am forced to disable it to get rid of it.

[connor4312]

Ah, sorry, lost the context and didn't realize you were on Insiders. It looks like there's a bad interaction between settings changes we made yesterday and a not-yet-bumped version of js-debug that came with that build of Insiders. This will be fixed in the next Insiders build (in a couple hours), which includes the corresponding change in the debugger. Thank you for the report!

For now you should be able to fix this by setting debug.javascript.autoAttachFilter to disabled (you may have noticed the setting I mentioned previously no longer exists on Insiders)

[sweettyler]

@connor4312 Sorry but I downloaded today's insider version (Commit: 403a689) and still get this error message pop up. Checked the time of your latest commit (75e55d1) and found it was not included in the build.

[connor4312]

It should be in the next Insiders -- please let me know if you hit it after that time

[JVimes]

Is this closed on purpose? It would be nice for us to verify it, first.

[connor4312]

We close issues when the fix is made in the source. Verification is asynchronous, and can happen from a community member or, if not, a team member as part of endgame. If an issue is still present after being released, it's reopened until a fix is committed.

This issue was originally closed as as-designed due to some confusion, but when we figured out what was wrong, the fix was made at that point, so I left it closed.

[pmsjt]

Well, the bug has "as designed" flag set, and we've established that is incorrect. Can we have that removed?

The problem with closing an issue before it is validated is that it may lead to people opening more and more issues if they are experiencing a problem and the only existing report of that is closed.

[connor4312]

Fair point, I removed the flag 🙂