vscode: Allow to configure the timeout for waiting to resolve shell environment
Issue Type: Bug
Javascript Debug Terminal not attaching debugger
1. Open a JavaScript Debug Terminal
2. Create `index.js` and attach breakpoints to the contents
3. Run `node index.js`
Actual: The code runs normally. Expected: The debugger attaches and the breakpoints are triggered.
Other Info:
My PATH:
/Users/piers/.nvm/versions/node/v14.17.0/bin:/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin:/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/bin:/Users/piers/dev/flutter/bin:/Library/Java/JavaVirtualMachines/openjdk-8.jdk/Contents/Home/bin:/Users/piers/dev/flutter/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Java/JavaVirtualMachines/openjdk-8.jdk/Contents/Home/bin
node version: 14.17.0 which node: /Users/piers/.nvm/versions/node/v14.17.0/bin/node
VS Code version: Code 1.60.0 (e7d7e9a9348e6a8cc8c03f877d39cb72e5dfb1ff, 2021-09-01T10:54:53.442Z) OS version: Darwin x64 20.5.0 Restricted Mode: No
Things attempted:
- Setting
Auto-attach: always- this triggers the errorWe did not findnodeon your PATH, so we cannot enable auto-attach in your environmentwhich links me to https://github.com/microsoft/vscode-js-debug/issues/708 - Switching from the nvm version of node to the brew version of node.
- Running
Debug: Force Enable Auto-Attachas suggested in the link - but this is not an available command - Setting
debug.javascript.usePreviewAutoAttachas suggested in the link, but this is also not an available setting. - Checking the log files. Nothing of note other than possibly two errors in the main log file:
[2021-09-08 16:23:18.929] [main] [error] [resolve shell env] Could not resolve shell environment within 10 seconds. Proceeding without shell environment... [2021-09-08 16:23:18.985] [main] [error] getUnixShellEnvironment#error An unknown error occurred. Please consult the log for more details.
System Info
| Item | Value |
|---|---|
| CPUs | Intel® Core™ i7-9750H CPU @ 2.60GHz (12 x 2600) |
| GPU Status | 2d_canvas: enabled gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on rasterization: enabled skia_renderer: disabled_off_ok video_decode: enabled webgl: enabled webgl2: enabled |
| Load (avg) | 2, 2, 2 |
| Memory (System) | 32.00GB (7.40GB free) |
| Process Argv | –crash-reporter-id f2039b3f-4da2-4e10-a09d-f641c4c7a6fe |
| Screen Reader | no |
| VM | 0% |
A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383cf:30185419
pythonvspyt602:30300191
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyt639:30300192
pythontb:30283811
pythonptprofiler:30281270
vsdfh931cf:30280410
vshan820:30294714
vstes263:30335439
pythondataviewer:30285071
pythonvsuse255:30340121
vscod805cf:30301675
pythonvspyt200:30340761
vscextlang:30333561
binariesv615:30325510
pythonvssor306:30344512
bridge0708:30335490
pygetstartedt2:30360495
bridge0723:30353136
pythonf5test824cf:30361778
pythonvspyt187:30362782
pydsgsc2:30361791
vscus224:30358039
vssid140cf:30363604
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 1
- Comments: 20 (8 by maintainers)
My initial shell startup time is rather long, around 15-20 seconds. It’s not a problem for me and it wouldn’t be a problem if VSCode also took that long to start because subsequent launches are very fast and a cold boot takes 3 minutes anyway so it’s comparatively insignificant. I’d greatly appreciate if this timeout was configurable.
A new setting
application.shellEnvironmentResolutionTimeoutto control this will be available starting tomorrow.Why isn’t this configurable?
I have a lot going on with my shell, and ten seconds or more to load it is fine by me.
I HAVE NEVER SEEN THIS BEHAVIOR FROM ANY OTHER SOFTWARE EVER.
Why is this not configurable?
When I shut down my macOS I always check
Then when I turn on the computer I always get Resolving shell environment fails. To resolve this issue I restart my VSCode. I agree with @lbfalvy it would be nice to have a configurable timeout as shown by @bpasero
I do use .nvm as node version manager and I don’t want to switch to asdf as suggested by official VSCode docs. Nvm is more popular and poplar things tend to stay longer and have more community support.
it’s sound sacrifice anything to get fast application boot but in the end, the app is useless and usually user will reboot again until ENV load properly
so, instead of hard code the timeout, just give a user power to configure it i guess user won’t complain if application boot taking a bit longer, just give a warning message about it user know their computer spec it’s normal
Ah, gotcha. The timeout was a red herring.
Ben I’ll leave this open in case you want to use this for tracking making the timeout configurable.
In settings. And currently this is only present in insiders until we ship a new stable release. You can give our preview releases a try from: https://code.visualstudio.com/insiders/
Verification:
sleep 12to your~/.bashrcor~/.zshrcfirst lineapplication.shellEnvironmentResolutionTimeoutsetting to a larger valuesleep 12againYou can give our preview releases a try from: https://code.visualstudio.com/insiders/
so, the timeout now is already configurable or still keep stick in 10 seconds? because the vscode documentation says still 10 seconds timeout https://code.visualstudio.com/docs/supporting/faq#_resolving-shell-environment-fails
We always gave up resolving the shell environment after 10 seconds, I did not change that, not even when introducing the shell environment service. We cannot really remove the timeout because processes like the extension host are waiting for the shell environment to be resolved and thus blocks from starting.
I think we probably need to introduce a setting for this for users that suffers or close this as wontfix.