fix(ruby_lsp): prevent duplicate clients on second buffer #4132
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
justinmk
reviewed
Oct 17, 2025
justinmk
reviewed
Oct 17, 2025
lsp/ruby_lsp.lua
Outdated
| return client.config.cmd_cwd == config.cmd_cwd | ||
| local client_cwd = client.config.cmd_cwd or client.root_dir | ||
| local config_cwd = config.cmd_cwd or config.root_dir | ||
| return client_cwd == config_cwd |
There was a problem hiding this comment.
why is this thing forcing root_dir to always be equal to CWD?
i would think this whole reuse_client can be dropped, assuming the other comment is addressed.
There was a problem hiding this comment.
The custom reuse_client was added in commit 903045b for monorepo support, but I don't fully understand why cmd_cwd comparison is necessary.
I don't have any monorepos that use ruby. This worked for me and i think it doesn't break the original monorepo support.
stask
force-pushed
the
fix/ruby-lsp-duplicate-clients
branch
from
324d022 to
dc8e56d
Compare
|
Updated the fix based on feedback:
This approach:
The commit has been squashed and the message updated. |
Problem: When opening multiple Ruby buffers, a second LSP client is spawned instead of reusing the first client, even though they share the same root directory. Root cause: The reuse_client function sets cmd_cwd as a side effect during reuse checks. This means the first client is created without cmd_cwd set, causing the reuse check to fail for the second buffer. Solution: Use before_init to ensure cmd_cwd is set for every client. Remove the custom reuse_client function to use Neovim's default reuse logic (compare name + root_dir). Testing: Tested with Neovim 0.11.4 by opening 3 Ruby files. All buffers now correctly reuse the first client.
stask
force-pushed
the
fix/ruby-lsp-duplicate-clients
branch
from
dc8e56d to
52b3eea
Compare
justinmk
reviewed
Oct 18, 2025
| }, | ||
| reuse_client = function(client, config) | ||
| before_init = function(_, config) | ||
| config.cmd_cwd = config.root_dir |
There was a problem hiding this comment.
sadly, before_init happens after the cmd is invoked, which means setting the cmd_cwd won't have the effect that was intended here.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem: When opening multiple Ruby buffers, a second LSP client is spawned instead of reusing the first client, even though they share the same root directory.
Root cause: The
reuse_clientfunction setscmd_cwdas a side effect during reuse checks. This means the first client is created withoutcmd_cwdset, causing the reuse check to fail for the second buffer.Solution: Use
before_initto ensurecmd_cwdis set for every client before initialization. Remove the customreuse_clientfunction to use Neovim's default reuse logic (compare name + root_dir).Testing: Tested with Neovim 0.11.4 by opening 3 Ruby files. All buffers now correctly reuse the first client.
Note:
lsp/ast_grep.luahas the identical pattern and likely has the same issue.