LSP fails to start: Could not find command "_2.5.22_".

[atruskie]

This was introduced recently by the following change in #2658 (which resolved #2532):

ruby-lsp/lib/ruby_lsp/setup_bundler.rb

Lines 194 to 203 in 72f019a

	# If there's a Bundler version locked, then we need to use that one to run bundle commands, so that the composed
	# lockfile is also locked to the same version. This avoids Bundler restarts on version mismatches
	base_bundle = if @bundler_version
	env["BUNDLER_VERSION"] = @bundler_version.to_s
	install_bundler_if_needed
	"bundle _#{@bundler_version}_"
	else
	"bundle"
	end

Now when trying to activate the LSP in Visual Studio Code I see the following error message:

Log excerpts:

Log output

2024-10-17 02:42:10.644 [info] (baw-server) Checking if chruby is available on the path with command: /bin/sh -i -c 'chruby --version'
2024-10-17 02:42:10.650 [info] (baw-server) Checking if rbenv is available on the path with command: /bin/sh -i -c 'rbenv --version'
2024-10-17 02:42:10.655 [info] (baw-server) Checking if rvm is available on the path with command: /bin/sh -i -c 'rvm --version'
2024-10-17 02:42:10.662 [info] (baw-server) Checking if asdf is available on the path with command: /bin/sh -i -c 'asdf --version'
2024-10-17 02:42:10.716 [info] (baw-server) Discovered version manager none
2024-10-17 02:42:10.716 [info] (baw-server) Running command: `ruby -W0 -rjson -e 'STDERR.print("RUBY_LSP_ACTIVATION_SEPARATOR" + { env: ENV.to_h, yjit: !!defined?(RubyVM:: YJIT), version: RUBY_VERSION }.to_json + "RUBY_LSP_ACTIVATION_SEPARATOR")'` in /home/baw_web/baw-server using shell: /bin/bash
2024-10-17 02:42:11.461 [info] (baw-server) Ruby LSP> Skipping custom bundle setup since LSP dependencies are already in /home/baw_web/baw-server/Gemfile

2024-10-17 02:42:11.559 [info] (baw-server) 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

2024-10-17 02:42:11.721 [info] (baw-server) Could not find command "_2.5.22_".

2024-10-17 02:42:11.876 [info] (baw-server) Could not find command "_2.5.22_".

2024-10-17 02:42:12.006 [info] (baw-server) Could not find command "_2.5.22_".

2024-10-17 02:42:12.008 [info] (baw-server) [Error - 2:42:12 AM] Server process exited with code 15.
2024-10-17 02:42:12.008 [info] (baw-server) [Error - 2:42:12 AM] Server initialization failed.
2024-10-17 02:42:12.009 [info] (baw-server)   Message: Pending response rejected since connection got disposed
  Code: -32097 
2024-10-17 02:42:12.009 [info] (baw-server) [Error - 2:42:12 AM] Ruby LSP client: couldn't create connection to server.
2024-10-17 02:42:12.009 [info] (baw-server)   Message: Pending response rejected since connection got disposed
  Code: -32097 
2024-10-17 02:42:12.009 [error] (baw-server) Error starting the server: Pending response rejected since connection got disposed
2024-10-17 02:42:47.436 [info] (baw-server) [Error - 2:42:47 AM] Connection to server got closed. Server will not be restarted.

I tried:

• updating bundler
• installing the lsp gems in my gem file

To avoid running the custom bundle workflow but nothing worked.

I don't understand how inserting _<version>_ between bundler and the command is meant to form a valid bundler command?

---

Ruby LSP Information

VS Code Version

1.94.2

Ruby LSP Extension Version

0.8.5

Ruby LSP Server Version

Unknown

Ruby LSP Addons

Ruby Version

3.2.2

Ruby Version Manager

none

Installed Extensions

Click to expand

• solargraph (0.24.1)
• gitlens (15.6.1)
• EditorConfig (0.16.4)
• copilot (1.239.0)
• copilot-chat (0.21.2)
• vscode-pull-request-github (0.98.0)
• vscode-test-explorer (2.22.1)
• vscode-rdbg (0.2.2)
• test-adapter-converter (0.2.0)
• ruby-lsp (0.8.5)
• code-spell-checker (3.0.1)

Ruby LSP Settings

Click to expand

Workspace

{}

User

{
  "enableExperimentalFeatures": false,
  "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
}

[mskog]

It seems like the issue is with the binstubs generated by Rails not being compatible with the underscore for setting bundler version, assuming that you are running a Rails project.
I have the same issue in my projects, running Rails 7.1 and 7.2. Regenerating the bundler binstub didn't help. Removing it did.

[mskog]

You can also set the Bundle Gemfile option to make the problem go away, because then it won't use the Rails bundler binstub:

"rubyLsp.bundleGemfile": ".ruby-lsp/Gemfile"

[vinistock]

Thank you for the report! On new Rails applications, it seems to work fine since the bundle binstub does account for the version being passed as an argument.

Does updating the binstub to the latest fix the issue for you?

[atruskie]

Thanks for the responses!

I had forgotten I even had binstubs to be honest. I did check the bundler man pages for the version syntax notation before I filed the issue though 😅

So, the issues still occurs when I use an updated bundler generated bin stub (bundle binstubs bundler --force). I think that's equivalent to what I was using before because my diff shows the regex (I think it's the correct one) remaining unchanged:

I also ran rails app:update:bin but that did not affect the bundler binstub.

Lastly, I generated a new rails application and copied the bundle binstub over the top of my current one and still received the error.

It seems like the issue is with the binstubs generated by Rails not being compatible with the underscore for setting bundler version, assuming that you are running a Rails project.
I have the same issue in my projects, running Rails 7.1 and 7.2. Regenerating the bundler binstub didn't help. Removing it did.

Seems to be the same for me.

You can also set the Bundle Gemfile option to make the problem go away, because then it won't use the Rails bundler binstub:
"rubyLsp.bundleGemfile": ".ruby-lsp/Gemfile"

This seems to work.

---

I've included my bundle binstub contents here: https://gist.github.com/atruskie/152df33ef32ce8899e63a992fbe28d64

[bjeanes]

I've also started getting this on an existing project. The binstubs haven't been updated since April, and the bundle one in particular hasn't been touched since 2017. This issue just started.

You can also set the Bundle Gemfile option to make the problem go away, because then it won't use the Rails bundler binstub:
"rubyLsp.bundleGemfile": ".ruby-lsp/Gemfile"

This also seems to work around it in meantime.

[siegbenn]

I've also started running into this issue on Rails (8.0.0.beta1) projects.

• I'm using mise to manage my Ruby versions and path to the binstubs in my Rails projects.
• I'm not using Visual Studio Code, I'm using Neovim (LazyVim) with the LSP plugin.

I have solved this by removing the bundle binstub in my Rails project bin directory.

[vinistock]

@atruskie thank you for sharing your binstub, that was helpful. I have the exact same binstub and I managed to get some better insights.

If I run exactly what the Ruby LSP runs, I don't get the error:

BUNDLE_GEMFILE=.ruby-lsp/Gemfile bundle _2.5.15_ exec ruby-lsp

but if I manually invoke the binstub, I do get the same error

BUNDLE_GEMFILE=.ruby-lsp/Gemfile bin/bundle _2.5.15_ exec ruby-lsp

The thing we need to understand now is, why is invoking bundle exec using the binstub automatically? Is there some sort of Bundler setting that makes it prefer binstubs?

[andyw8]

@atruskie do you happen to have bin/ (or ./bin/) on your PATH?

[mskog]

I think that is the issue indeed @andyw8. I also use mise-en-place with an alias that makes the bundle command use the binstub if it exists. That is written in such a way that invoking bundle exec from Ruby LSP will also use the binstub.

[vinistock]

So the alias overrides the bundle command completely? Is there no way to invoke bundle exec without the alias?

If that's the case, I'm not sure what we can do from our side. We want to invoke bundle exec using the version that has been locked in your project to avoid Bundler version mismatch restarts, which lead to a failure to boot.

I wonder if the bundle binstub not accepting a version is intentional and if we could change that instead.

[atruskie]

Yup, that's it, the ./bin folder is on my PATH. All the binstubs my project needs are in bin, including bundler and rails.

I'll confess, I'm not an expert. I don't know whether all that is best practice or not, but it's worked for a long time, and it made sense (though I'm now suspecting one isn't manually supposed to invoke binstubs now?).

I also don't have any ruby/gems versioning needs because I'm running in a container.

Oh also: I get my docker build to install exactly the version of bundler that was used to bundle the bundle. So I myself never have mismatched bundler versions

[rmehner]

Thank you so much for mentioning the problem with ./bin being in $PATH being the problem here. Once I've removed that, everything works fine again with Zed.

[bjeanes]

We ended up deleting bin/bundle. We're working out of a devcontainer so there chance of gem version conflicts is pretty minimal, so the binstubs are less important anyway.

[vinistock]

Is it the case for everyone on this thread that ./bin was in their PATH? If this is the case for all of you, then we could add a check to not concatenate the version string if ./bin is in the PATH and a bin/bundle exists.

If you can all confirm if this is the scenario, then we can push a fix.

[siegbenn]

That was the case with me @vinistock.

[bjeanes]

If you can all confirm if this is the scenario, then we can push a fix.

Yes, this is the case effectively but not literally. For us, in a VSCode devcontainer:

➜  /app git:(main) pwd
/app
➜  /app git:(main) echo $PATH
/root/.vscode-server/bin/384ff7382de624fb94dbaf6da11977bba1ecd427/bin/remote-cli:/app/bin:/usr/local/bundle/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

So in our case the project directory's bin is in the path. That could be considered $CWD/bin / "#{Rails.root}/bin" depending on perspective.

[jonleighton]

we could add a check to not concatenate the version string if ./bin is in the PATH and a bin/bundle exists.

The _version_ thing is Rubygems magic, right? Perhaps you could find the path that bundle resolves to (i.e. which bundle), and then see if that path is the binary from an installed gem, or something else (i.e. a bin/bundle binstub). Depending on which one it is, decide whether to add the _version_ arg.