Ruby LSP: indexing files: 0% completed hangs forever

[argent-smith]

Description

Hi. On my project, I see "Ruby LSP: indexing files: 0% completed" notification and progress spinner — they stay forever

Configuration:
VScode 1.91.0
Ruby LSP plugin v0.7.11
ruby-lsp in the project's bundle 0.17.6

[andyw8]

Hi @argent-smith, can you try running ruby-lsp-doctor in your repo, and see if it hangs.

[andyw8]

And also check for any errors in the Ruby LSP output panel.

[argent-smith]

can you try running ruby-lsp-doctor in your repo, and see if it hangs

Hi @andyw8, ruby-lsp-doctor doesn't hang

And also check for any errors in the Ruby LSP output panel.

It looks like this:

[argent-smith]

@andyw8 also, this works fine:

⟩ bundle exec ruby-lsp --time-index
Ruby LSP v0.17.6: Indexing took 9.86661 seconds and generated:
- Module: 14269
- Class: 9314
- Method: 72038
- InstanceVariable: 23228
- Accessor: 9433
- UnresolvedMethodAlias: 3000
- Constant: 7616
- SingletonClass: 3208
- UnresolvedAlias: 434

[andyw8]

Thanks, please also check here for errors (choose Output, then select Ruby LSP):

[argent-smith]

@andyw8 thank you for the point. I've found and fixed the problem! Thanks to all the contributors for a great tool!

[argent-smith]

Fixed

[andyw8]

Note: The ruby-lsp-doctor command is now ruby-lsp --doctor (#2310)

[thewatts]

I was having the same

• Ruby 3.3.4
• ruby-lsp 0.17.15

I run ruby-lsp --doctor and get no errors, and my editor nvim just hangs saying that it's at 0%.

Our issue: we needed to upgrade standard.

---

Note: I attempted to upload screenshots, but for some reason it's not working at the moment.

[pablosanderman]

A senior dev helped me fix it, here's what he did:

First we went to the output tab on vscode, and then selected Ruby LSP in the accordion top right.

We saw that a gem couldn't be installed.

Then we went to Preferences: Open Settings (UI), clicked the extensions tab, then Ruby LSP tab, then we saw that the Bundle Gemfile field waws filled with a path. This should've been empty, but our company configured it to a path, so normal ruby or rails projects couldn't use Ruby LSP.

It should be empty

[baelter]

I'm getting a similar issue. Ruby LSP fail to start because it can load a gem required by a rubocop config in a parent folder which shouldn't even be in use since to project has its own. Either way, the gem is installed for the ruby version in use.

They are not installed in the current bundle though.

2024-10-23 11:03:21.224 [info] (rubocop-eightyfourcodes) Finished initializing Ruby LSP!
2024-10-23 11:03:21.473 [info] (rubocop-eightyfourcodes) Error processing initialized: /home/anders/.rbenv/versions/3.3.5/lib/ruby/gems/3.3.0/gems/rubocop-1.67.0/lib/rubocop/feature_loader.rb:46:in `rescue in rescue in load': cannot load such file -- rubocop-gitlab-security (LoadError)
...
	from /home/anders/.rbenv/versions/3.3.5/lib/ruby/gems/3.3.0/gems/ruby-lsp-0.20.1/lib/ruby_lsp/requests/support/rubocop_runner.rb:86:in `initialize'

[baelter]

Moved my default config to ~/.config/rubocop/config.yml solved it

[vinistock]

They are not installed in the current bundle though.

Bundler doesn't allow you to require any gems that aren't a part of the bundle. It explicitly sets up the $LOAD_PATH to prevent that from happening, so we need all RuboCop extensions to be included in it.

It doesn't matter if they are in a separate Gemfile that you evaluate from the main Gemfile or any other structure, but they need to be a part of the bundle.

[mrbongiolo]

I had a similar issue running ruby-lsp with neovim . It always hang in "indexing files: 0%".

The harder part was that --doctor, logs, and debug didn't show any error; it only hung when the lsp was started within Neovim (installed via Mason).

In the end, the problem was that .rubocop.yml file referenced rubocop-rails-omakase in inherited_gem section, but we changed rubocop-rails-omakase for standardrb in the project Gemfile.

Removing that line solved the issue, or even removing the .rubocop.yml file solves the issue.

[vinistock]

@mrbongiolo that's interesting, did you notice if you had anything printed to the output tab? I can understand the linting/formatting not working under those conditions, but if indexing broke too there's a chance that we're not handling errors gracefully somewhere.

Is having a .rubocop.yml file with the omakase thing, but using Standard enough to reproduce?

[mrbongiolo]

@vinistock Doing some tests here.

A simple test case is having such a Gemfile:

source "https://rubygems.org"

# gem "rubocop-rails-omakase", require: false
gem "rubocop"

And a .rubocop.yml file like that:

# Omakase Ruby styling for Rails
inherit_gem: { rubocop-rails-omakase: rubocop.yml }

When I open the Gemfile in neovim, the LSP is stuck at 0% indexing files.

The logs show this:

[ERROR][2024-11-05 22:58:08] .../vim/lsp/rpc.lua:770    "rpc"   "/home/mrbongiolo/.local/share/nvim/mason/bin/ruby-lsp" "stderr"        "Ruby LSP> Skipping custom bundle setup since /home/mrbongiolo/projects/ruby-lab/.ruby-lsp/Gemfile.lock already exists and is up to date\n"
[ERROR][2024-11-05 22:58:08] .../vim/lsp/rpc.lua:770    "rpc"   "/home/mrbongiolo/.local/share/nvim/mason/bin/ruby-lsp" "stderr"        "Ruby LSP> Running bundle install for the custom bundle. This may take a while...\nRuby LSP> Command: (bundle _2.5.22_ check || bundle _2.5.22_ install) 1>&2\n"
[ERROR][2024-11-05 22:58:08] .../vim/lsp/rpc.lua:770    "rpc"   "/home/mrbongiolo/.local/share/nvim/mason/bin/ruby-lsp" "stderr"        "The Gemfile's dependencies are satisfied\n"

The LSP info display this:

lspconfig: require("lspconfig.health").check()

LSP configs active in this session (globally) ~
- Configured servers: jsonls, lua_ls, ruby_lsp, gopls, marksman
- OK Deprecated servers: (none)

LSP configs active in this buffer (bufnr: 1) ~
- Language client log: ~/.local/state/nvim/lsp.log
- Detected filetype: `ruby`
- 1 client(s) attached to this buffer
- Client: `ruby_lsp` (id: 1, bufnr: [1])
  root directory:    ~/projects/ruby-lab/
  filetypes:         ruby
  cmd:               ~/.local/share/nvim/mason/bin/ruby-lsp
  version:           `0.21.3`
  executable:        true
  autostart:         true

It's kinda weird that running --doctor directly from the project seems to work:

❯ ~/.local/share/nvim/mason/bin/ruby-lsp --doctor
Ruby LSP> Skipping custom bundle setup since /home/mrbongiolo/projects/ruby-lab/.ruby-lsp/Gemfile.lock already exists and is up to date
Ruby LSP> Running bundle install for the custom bundle. This may take a while...
Ruby LSP> Command: (bundle _2.5.22_ check || bundle _2.5.22_ install) 1>&2
The Gemfile's dependencies are satisfied
Globbing for indexable files
indexing: /home/mrbongiolo/.asdf/installs/ruby/3.3.5/lib/ruby/3.3.0/English.rb
indexing: /home/mrbongiolo/.asdf/installs/ruby/3.3.5/lib/ruby/3.3.0/abbrev.rb
indexing: /home/mrbongiolo/.asdf/installs/ruby/3.3.5/lib/ruby/3.3.0/base64.rb
indexing: /home/mrbongiolo/.asdf/installs/ruby/3.3.5/lib/ruby/3.3.0/benchmark.rb
indexing: /home/mrbongiolo/.asdf/installs/ruby/3.3.5/lib/ruby/3.3.0/bigdecimal/jacobian.rb
indexing: /home/mrbongiolo/.asdf/installs/ruby/3.3.5/lib/ruby/3.3.0/bigdecimal/ludcmp.rb
indexing: /home/mrbongiolo/.asdf/installs/ruby/3.3.5/lib/ruby/3.3.0/bigdecimal/math.rb
indexing: /home/mrbongiolo/.asdf/installs/ruby/3.3.5/lib/ruby/3.3.0/bigdecimal/newton.rb
# and many other files until it seems to execute successfully

I don't have vscode currently installed on my Windows setup to try to replicate there.