LSP server crash can leave the extension in a stuck state

[Earlopain]

Operating System

Windows 11

Ruby version

3.2.2

Project has a bundle

• Has bundle

Ruby version manager being used

rbenv

Description

There are a few issues here I believe:

When using a custom gemfile and that gemfile gets updated the server crashes. The required gems are not installed => it can't start up anymore. This is documented in the readme:

Note: when using this, gems will not be installed automatically and neither will ruby-lsp upgrades.

That error message isn't nicely surfaced however, you need to look in the extension output instead. Related to/Same as #1769 I would say.

However, through that crash the LSP client gets the internal state startFailed, which results in the Restart/Stop/Start commands not working even after the issues has been fixed. You have to perform a Window reload instead:

Restart (logged to output only):

Error restarting the server: Client is not running and can't be stopped. It's current state is: startFailed

Start/Stop:

This happens because through some codepath they all end up calling dispose. This fails because there is no active connection:
https://github.com/microsoft/vscode-languageserver-node/blob/c0982bf544bab9600df223146dd75c93c9004dc3/client/src/common/client.ts#L1374-L1376

I looked through the public API but didn't immediatly find something that would hint to that being the case. The exposed client states are also more limited to than what vscode works with internally (state vs $state which is private)

[vinistock]

Thank you for the bug report!

For surfacing nicer Bundler errors, we have this issue #1769. I think we can add a custom error handler and do a much better job of showing what went wrong.

Regarding restarting the server, it's interesting that the state is not a part of the state exposed in the client. We try to handle all states here, but clearly that one is kind of a "sub-state" not listed in that enumerable type.

We need to figure out how we can determine that the client is in the startFailed state, so that we can avoid invoking stop on it and instead just dispose and create a fresh client.

[lpender]

I have this issue too in Os X. Uninstall / reinstall / restart computer didn't fix it.

EDIT: This is a better solution.

I had to do this:

gem install ruby-lsp
ruby-lsp

Or to keep it running in the background:

nohup ruby-lsp &

in a terminal window.

[vinistock]

Unless I'm missing something, if you run the server in the background with nohup, you're basically using it to run bundle install.

The extension has no knowledge that the process is running from the terminal nor does it have ownership over the STDIN, STDERR and STDOUT pipes to communicate with it.

That's just running bundle install for the custom bundle with the background process and then the extension spawns a second process (owned by the extension) and boots the server.

If you inspect the processes for ruby-lsp, you'll likely have two running, no?

ps aux | grep ruby-lsp

[lpender]

No, I just see processes for ruby_lsp_rails/server.rb and ruby-lsp

I'm not sure how that's equivalent to it running bundle install, but the fact is that the extension did not work in VSCode before I did this.

Whether I call Ruby LSP: Stop, Start, Restart, the output says Error restarting the server: Client is not running and can't be stopped. It's current state is: startFailed).

That said, I finally got it to work properly:

gem uninstall `ruby-lsp` 
gem uninstall `ruby-lsp-rails`

2. Uninstall and re-install VSCode extension
3. Reload VSCode.

[vinistock]

I'm not sure how that's equivalent to it running bundle install, but the fact is that the extension did not work in VSCode before I did this.

As part of launching the server, we set up a custom bundle under the .ruby-lsp directory so that you don't have to include the gem in your application's dependencies and then we run bundle install.

If you run ruby-lsp in the terminal, the only thing that happens is you setup the custom bundle, run bundle install and then the server keeps waiting for input forever until its terminated (because the editor is not connected to it, so it never receives any requests).

Anyway, I'm glad it's fixed.

[yndajas]

gem uninstall `ruby-lsp` 
gem uninstall `ruby-lsp-rails`

2. Uninstall and re-install VSCode extension
3. Reload VSCode.

This worked for me just now. After upgrading from Ruby 3.2.2 to 3.2.4, I accidentally switched the Ruby formatter to rubocop.vscode-rubocop by mistake, which runs a lot slower than Shopify.ruby-lsp in my setup. When trying to revert to using the Ruby LSP as the formatter (using RuboCop under the hood), I was encountering issues like Shopify/vscode-shopify-ruby#443 and #1866. The steps above as described by @lpender seem to have fixed things

[vinistock]

I believe this has been fixed in recent versions of the extension. Please let us know if that's not the case.

[Earlopain]

Yes, I think you are right. I can't actually remember the last time I ran into this. I guess there was some critical part where it really shouldn't have crashed and now it doesn't.