Hangs at "Ruby LSP: Starting" / "Starting Ruby LSP..." indefinitely, no features available

[PaulScorthorne]

Operating System

Windows 10

Ruby version

3.2.2

Project has a bundle

• Has bundle

Ruby version manager being used

no manager

Description

After the fix was made to my previous issue #1708, I have once again been happily using Ruby LSP for the last few weeks. Then this morning when I launched VSCode none of the Ruby LSP features were working.

Running through the troubleshooter I noticed that the Status of Ruby LSP was listed as Starting. No Command Pallet actions seemed to affect this status. Launching the server manually from the terminal gets to "Starting Ruby LSP..." but no further, and still no features are useable:

ruby-lsp Ruby LSP> Skipping lockfile copies because there's no top level bundle Ruby LSP> Running bundle install for the custom bundle. This may take a while... Ruby LSP> Command: (bundle check || bundle install) 1>&2 The Gemfile's dependencies are satisfied Starting Ruby LSP...

The Ruby LSP Output channel is completely blank. I can't see any logging of Ruby LSP doing anything or any errors that might be helpful.

I have tried the release v0.5.4 as well as the pre-release v0.6.0 and both display this same issue.

I note other similar recent reports, but I am not (to my knowledge) operating in a multi-root workspace or with a nested gemfile etc. and as mentioned, Ruby LSP was working without issue until very recently.

Apologies if this is a duplicate of one of the other issues, appreciate the work being put in on this extension despite the occasional hiccups.

[PaulScorthorne]

Opening the sub-folder of the project where my tests live in VSCode directly activated the extension correctly, so it looks like Ruby LSP is now only activating if the workspace is at root, which seems presumptuous and significantly worse than whatever it was doing previously (which just worked).

However, I'll take any workaround I can get, and maybe that points the way to a fix?

[vinistock]

What's your project structure? Do you have multiple projects inside the same directory?

We recently updated the Ruby LSP to properly handle multi-root workspaces - it was actually not following VS Code guidelines before. Here's the documentation for it.

[stillhart]

I think I run into an issue regarding this. I have many folders in my workspace and it spawns more processes than my server/computer can handle. Ruby LSP is quite memory and cpu intensive, this times 40x during startup results in OOM killer. I think there needs to be a way to either slow this down, share each process by ruby version or start it on demand.

Right now I can't use ruby-lsp because of this change. I have around 20 folders in my workspace

[stillhart]

Maybe just add at least one debug message to the outputs in which workspace/folder a server is starting. Right now I can't even pin down why it is happening.

[vinistock]

@stillhart can you please create a separate issue for that?

I think a good compromise might be making all language server activations lazy except for the first workspace (so that people using a single workspace start indexing ahead of time). It'll still be memory heavy if you eventually lazily activate all workspaces though.

Sharing between Ruby versions wouldn't work if you have different lockfiles per workspace. The Ruby LSP indexes the files for gems using the specific versions that are currently locked and those could be different between workspaces.