ruby-lsp vscode extension + asdf breaks PATH, breaking other vscode extensions

[q3aiml]

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:

PATH=/Users/user/.asdf/installs/ruby/3.3.1/lib/ruby/gems/3.3.0/bin:/Users/user/.asdf/installs/ruby/3.3.1/bin:/Users/user/.asdf/shims:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.

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

Possible Cause

After some digging this seems to be due to a combination of #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: microsoft/vscode#13292 microsoft/vscode#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.

Thanks for reading!

[g-arjones]

ruby-lsp/vscode/src/ruby.ts

Lines 186 to 187 in 722e4a8

	// We need to set the process environment too to make other extensions such as Sorbet find the right Ruby paths
	process.env = env;

This is terrible... and scary.

[vinistock]

Thank you for the bug report. We just cut a release for v0.7.0 which should fix the errors introduced in the ASDF refactor.

Concerning modifying the process env, it was simply the easiest option to make other Ruby related extensions select the right Ruby version while we worked to mature the integrations for chruby, rbenv, ASDF, Shadowenv, Mise, RubyInstaller, RVM, custom integrations and manual Ruby version selection.

Once the implementation is mature enough, the idea is to turn Ruby activation into a different VS Code extension that all other Ruby extensions can depend on. That will allow users to be prompted only once for their Ruby environment configuration and all extensions will then have access to the Ruby environment object in order to decide how to launch with information coming from the version managers.