vscode: Revisit hardcoded timeout for resolving shell environment blocking first window open

@connor4312 After I restart vscode I don’t have the problem any more. I tried to reproduce it but I can’t

Developer: Reload Windows resolved my issue. Might not work for you just try. It worked for me.

I had same problem after upgrading to 1.49.0.

Just a comment to those finding this issue. My vscode instance was loaded by MacOS on a reboot using the “reopen all windows” option. So I believe it was started before the path was set for node in my shell. After closing and restarting vscode again manually it seemed to work just fine. Not sure if this is the case for everyone, but maybe an idea to help debug.

Hi added console: integratedTerminal fixed the problem, but even more strange is that after I restarted vscode the problem goes away!

I didn’t remember whether I restarted vscode yesterday but today that did fix the problem!

In case anyone else comes across this, this problem started for me after installing the macOS Big Sur 11.1 update.

Same problem Developer: Reload windows solved it

But I really see no reason why resolving the shell environment would take any longer than <1s.

It happens a lot, and that’s why it was set to 10.

Note that this blocks the window from opening, so it is really bad for performance

@jrieken made sure this doesn’t block the window from opening, just the workbench from loading, back when he introduced lazyEnv. @bpasero, this is now known as whenEnvResolved, since your latest refactorings.

Overall, the user env is really only needed when further spawning more processes, so the real fix here is to just have an IExecutionService which should get the user env whenever spawning processes, instead of having that dependency in the renderer. This is a big refactoring which will likely break many things, but it’s the right thing to do. I’ve created this item to follow up: https://github.com/microsoft/vscode/issues/108804. Note that while the workbench will load more things, a lot of other things can’t really work until the user env is loaded or timed out: terminals, tasks, extension host. Probably more, since we have configuration setting values which depend on environment values… So that’s fun.

Until then, I suggest to revert to the 10s timeout. Adding a setting for it is not good. Because every single user timing out will always file an issue before they even consider searching for a setting.

fyi @joaomoreno on my change. I really think this is not the right solution all in all because for a user you may be surprised that opening the first window always takes up to 10s (now 3s) without fully understanding what is going on in the background.

I think a setting for this could work, but is hard to discover too. Alternatively we could simply proceed with opening the workbench and let the process environment come in async with possibly an event to emit once that happens so that parties that need to update can subscribe to?

I had the same problem. Many of you restarted VScode so i tried it and it solved the problem. Thanks you guys.

That’s coming from your shell.

In js-debug to find Node we run which node or where node in the current environment. https://github.com/microsoft/vscode-js-debug/blob/8581c0bcda559b775d8666fb5765641c4118498b/src/common/pathUtils.ts#L15 Your observation that running npm directly does not find Node validates that the environment is wrong in the ext host.

As a workaround, you may be able to get things to work by setting console: integratedTerminal in your launch config along with the runtime executable, so that your program is run in a real shell.

@sandy081 / @isidorn did something change in 1.49 that would interfere with the environment that the extension host receives?

I have this issue too with 1.50. never had with 1.49 ( or at least it never happened ). Solved with Developer: Reload windows

Had the problem using vscode 1.49.3 and NVM on a project that had .vscode configuration without runtimeVersion set.

I set “runtimeVersion”: “12.16.3” which is the active NVM version and it worked.

@MatayoshiMariano nvm is a known case where (in their default install) we won’t always pick it up, because it’s set in your .bashrc which isn’t run by VS Code and won’t be applied unless you launch code from the command line. See here microsoft/vscode-js-debug#717 (comment)

Before upgrading 1.49 everything was working fine

I’m using also nvm and never head a problem before updating to 1.49. Problem was gone for days and appeared suddenly again some days ago. Restarting VSCode fixed it.

Same problem here when platform is WSL but works fine when platform is Windows.

Version: 1.49.1 (user setup) Commit: 58bb7b2331731bf72587010e943852e13e6fd3cf Date: 2020-09-16T23:27:51.792Z Electron: 9.2.1 Chrome: 83.0.4103.122 Node.js: 12.14.1 V8: 8.3.110.13-electron.0 OS: Windows_NT x64 10.0.20170

Opened VS Code from WSL terminal ( code . ) and Launch Program

Received error message: Can’t find Node.js binary “node”: path does not exist. Make sure Node.js is installed and in your PATH, or set the “runtimeExecutable” in your launch.json

Output from: echo "$PATH" (in WSL: Ubuntu-20.04 terminal) /home/greg/.asdf/shims:/home/greg/.asdf/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/c/Python38/Scripts/:/c/Python38/:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/WINDOWS/System32/WindowsPowerShell/v1.0/:/c/WINDOWS/System32/OpenSSH/:/c/Program Files/PowerShell/7/:/c/Program Files/dotnet/:/c/Program Files/Git/cmd:/c/Program Files/Docker/Docker/resources/bin:/c/ProgramData/DockerDesktop/version-bin:/c/Program Files/nodejs/:/c/ProgramData/chocolatey/bin:/c/Users/Greg/AppData/Local/Microsoft/WindowsApps:/c/Users/Greg/AppData/Local/Programs/Microsoft VS Code Insiders/bin:/c/Users/Greg/AppData/Roaming/npm:/c/Users/Greg/AppData/Local/Programs/Microsoft VS Code/bin:/snap/bin:/home/greg/.local/bin:/usr/local/go/bin:/home/greg/go/bin:/home/greg/dart-sass:/home/greg/.fzf/bin:/home/greg/.local/bin:/usr/local/go/bin:/home/greg/go/bin:/home/greg/dart-sass

Output from: which node (in WSL: Ubuntu-20.04 terminal) /home/greg/.asdf/shims/node

Output from: process.env['PATH'] (in VS Code dev console) C:\Python38\Scripts;C:\Python38;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0;C:\WINDOWS\System32\OpenSSH;C:\Program Files\PowerShell\7;C:\Program Files\dotnet;C:\Program Files\Git\cmd;C:\Program Files\Docker\Docker\resources\bin;C:\ProgramData\DockerDesktop\version-bin;C:\Program Files\nodejs;C:\ProgramData\chocolatey\bin;C:\Users\Greg\AppData\Local\Microsoft\WindowsApps;C:\Users\Greg\AppData\Local\Programs\Microsoft VS Code Insiders\bin;C:\Users\Greg\AppData\Roaming\npm;C:\Users\Greg\AppData\Local\Programs\Microsoft VS Code\bin

No WSL paths!

Works with work-around by adding:

"linux": {
        "runtimeExecutable": "/home/greg/.asdf/shims/node"
}

to launch.json

launch.json:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "type": "node",
            "request": "launch",
            "name": "Launch Program",
            "skipFiles": [
                "<node_internals>/**"
            ],
            "program": "${workspaceFolder}/app.js",
            "linux": {
                "runtimeExecutable": "/home/greg/.asdf/shims/node"
            }
        }
    ]
}

Also just to check, switched to Windows with Remote-WSL: Reopen Folder in Windows and Launch Program

No errors, works fine.

All above is reproducible.

I have the same problem after I upgraded to 1.49 !

Version: 1.49.0
Commit: e790b931385d72cf5669fcefc51cdf65990efa5d
Date: 2020-09-10T17:39:53.251Z
Electron: 9.2.1
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Darwin x64 19.6.0

I hit this error

If I changed runtimeExecutable I hit the following error

If I changed runtimeExecutable and runtimeArgs I hit the following error