Hanging on "running 'Ruby LSP' formatter"

[DEfusion]

Description

I've been having this issue on and off for some time now, some days it happens multiple times in quick succession and I have to quit VS Code (which then instantly crashes on re-open) some days it barely happens, all in the same project.

In December I completely removed my VS Code install and the Ruby LSP gem but that hasn't resolved it.

Ruby LSP Information

VS Code Version

1.96.4

Ruby LSP Extension Version

0.8.19

Ruby LSP Server Version

0.23.7

Ruby LSP Add-ons

• Ruby LSP Rails
• RuboCop

Ruby Version

3.2.6

Ruby Version Manager

rbenv

Installed Extensions

Click to expand

• LiveServer (5.7.9)
• atom-keybindings (3.3.0)
• coffeesense (1.15.0)
• copilot (1.260.0)
• copilot-chat (0.23.2)
• cucumberautocomplete (3.0.5)
• errorlens (3.22.1)
• even-better-toml (0.21.2)
• gitlens (16.2.1)
• incrementor (1.0.3)
• material-icon-theme (5.19.0)
• multi-cursor-case-preserve (1.0.5)
• rails (0.22.0)
• rainbow-csv (3.15.1)
• regex (0.5.1)
• remote-containers (0.394.0)
• ruby-extensions-pack (0.1.12)
• ruby-lsp (0.8.19)
• sorbet-vscode-extension (0.3.37)
• stimulus-lsp (1.0.4)
• string-converter (0.1.2)
• template-string-converter (0.6.1)
• visible-whitespace (0.0.6)
• vscode-docker (1.29.4)
• vscode-eslint (3.0.10)
• vscode-github-actions (0.27.0)
• vscode-import-cost (3.3.0)
• vscode-mdx (1.8.13)
• vscode-open-in-github (1.18.0)
• vscode-rdbg (0.2.2)
• vscode-stylelint (1.4.0)
• vscode-todo-plus (4.19.1)
• vsliveshare (1.0.5948)

Ruby LSP Settings

Click to expand

Workspace

{}

User

{
  "enabledFeatures": {
    "codeActions": true,
    "diagnostics": true,
    "documentHighlights": true,
    "documentLink": true,
    "documentSymbols": true,
    "foldingRanges": true,
    "formatting": true,
    "hover": true,
    "inlayHint": true,
    "onTypeFormatting": true,
    "selectionRanges": true,
    "semanticHighlighting": true,
    "completion": true,
    "codeLens": true,
    "definition": true,
    "workspaceSymbol": true,
    "signatureHelp": true,
    "typeHierarchy": true
  },
  "featuresConfiguration": {},
  "addonSettings": {},
  "rubyVersionManager": {
    "identifier": "auto"
  },
  "customRubyCommand": "",
  "formatter": "auto",
  "linters": null,
  "bundleGemfile": "",
  "testTimeout": 30,
  "branch": "",
  "pullDiagnosticsOn": "both",
  "useBundlerCompose": false,
  "bypassTypechecker": false,
  "rubyExecutablePath": "",
  "indexing": {},
  "erbSupport": true,
  "featureFlags": {}
}

Reproduction steps

No idea, like I say sometimes it happens a lot, sometimes barely at all. All I am doing is editing a Ruby file and saving it.

[vinistock]

Thank you for the report. When the formatting dialog never goes away, it means the server got stuck or crashed. This might be the problem reported in #2446, which I hope was fixed by #2976.

When you say that sometimes it happens a lot and sometimes barely at all, is that across projects? If so, then it could be that some of the projects aren't on the latest Ruby LSP with the fixes.

[DEfusion]

I'll keep an eye out for CPU usage if it hangs again.

It is an issue across multiple projects, I just did a search for what versions of the gems were installed and uninstalled them all then restarted vs code.

I opened up one project and after the extension had initialised I had:

ruby-lsp (0.23.8)
ruby-lsp-rails (0.3.31)

I opened another project and then after extension initialised I have:

ruby-lsp (0.23.8, 0.23.7)
ruby-lsp-rails (0.3.31)

Why would opening the second project mean I have 0.23.7 installed? I haven't got it defined as a dependency and they're both on ruby 3.2.6.

[vinistock]

Whenever the Ruby LSP is launched, there are always two gem versions. The first one is what you have globally installed (since we invoke ruby-lsp with no bundle exec). That one is used to compose the bundle under the .ruby-lsp directory, so that the language server can connected to your project's dependencies. However, that's not the version of the server that will actually be running once we finish booting.

The version locked in .ruby-lsp/Gemfile.lock is the one that is actively running in the editor. That one can be affected by your project's dependencies because Bundler will take all constraints into account when installing. For example, a common issue is projects that have rbs older than v3 installed, which then means the bundle cannot satisfy the Ruby LSP's dependencies.

We auto-upgrade both the global installations and the one locked in the composed bundle, but this happens gradually and for the second one, your dependencies may constrain the updates.

We also only auto-upgrade if your bundle is already satisfied. For example, if you git pull and there's a commit upgrading a gem, we will run bundle install rather than bundle update, preferring to satisfy the bundle over trying to upgrade the LSP.