Hi everyone! I've noticed various vscode extensions breaking over the last few days. The behavior seems non-deterministic. Sometimes they fail from the start. Other times they boot fine and fail later. For example Sorbet eventually gets into an endless restart loop, exiting continually with Error running Watchman.
The vscode logs didn't shine a lot of light on this. I eventually caught a sorbet process before it died and found an unexpected value for PATH:
It was overwritten, missing many things normally in my PATH like homebrew. But vscode starts out with the correct PATH. Restarting the extension host sometimes temporarily fixes the problem, sometimes not.
vscode extension version 0.5.20
vscode version 1.88.1
On one hand I can see the motivation for mutating the environment given the issue reports that have been received. But for me it was a surprising discovery. I setup my environment correctly and I did not expect ruby-lsp to silently change it across all extensions. It would have helped me debug if the extension at least logged that it was doing so.
Mutating the environment also seems a bit fraught given that extensions apparently do not load in a controllable order: https://github.com/microsoft/vscode/issues/13292https://github.com/microsoft/vscode/issues/57481. I assume that explains why the startup behavior seems non-deterministic: sometimes ruby-lsp changes the PATH before other extensions read it and sometimes it changes it after.
Summary
Sorry for being long-winded. In summary:
In my environment the new ASDF integration is changing PATH to a broken value. This surprisingly impacts all extensions.
Overwriting environment for all extensions seems problematic. But at a minimum it'd be nice to log that it is happening.
Description
Hi everyone! I've noticed various vscode extensions breaking over the last few days. The behavior seems non-deterministic. Sometimes they fail from the start. Other times they boot fine and fail later. For example Sorbet eventually gets into an endless restart loop, exiting continually with
Error running Watchman
.The vscode logs didn't shine a lot of light on this. I eventually caught a sorbet process before it died and found an unexpected value for
PATH
:It was overwritten, missing many things normally in my PATH like homebrew. But vscode starts out with the correct PATH. Restarting the extension host sometimes temporarily fixes the problem, sometimes not.
vscode extension version
0.5.20
vscode version1.88.1
Possible Cause
After some digging this seems to be due to a combination of https://github.com/Shopify/ruby-lsp/pull/1845 and the
Process.env
mutation in runActivation.I've checked the Ruby LSP extension logs but do not see a log message containing the full command for the activation script or its output. Yet if I am reading asdf.ts correctly, it seems like the only environment passed to the activation script is ASDF_DIR and ASDF_DATA_DIR. That would explain why the usual contents of PATH are lost.
On one hand I can see the motivation for mutating the environment given the issue reports that have been received. But for me it was a surprising discovery. I setup my environment correctly and I did not expect ruby-lsp to silently change it across all extensions. It would have helped me debug if the extension at least logged that it was doing so.
Mutating the environment also seems a bit fraught given that extensions apparently do not load in a controllable order: https://github.com/microsoft/vscode/issues/13292 https://github.com/microsoft/vscode/issues/57481. I assume that explains why the startup behavior seems non-deterministic: sometimes ruby-lsp changes the PATH before other extensions read it and sometimes it changes it after.
Summary
Sorry for being long-winded. In summary:
Thanks for reading!