`protols` crashes when receiving foreign LSP notifications from other language servers

[vasigorc]

Problem

protols crashes with a panic when it receives notifications from other LSP servers running in the same Neovim session. This happens in multi-language projects where multiple LSP servers are active simultaneously (in my case it is a project that uses Scala and Protocol Buffers).

Error

thread 'main' panicked at <REDACTED>.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/protols-0.11.5/src/main.rs:94:46:
called `Result::unwrap()` on an `Err` value: Routing("Unhandled notification: metals/didFocusTextDocument")
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Steps to Reproduce

1. Open a project containing both .proto and .scala files in Neovim
2. Configure both protols (for Protocol Buffers) and metals (for Scala) LSP servers
3. Open a .proto file (protols starts)
4. Open a .scala file (metals starts)
5. Focus on the Scala file
6. protols crashes when metals sends metals/didFocusTextDocument notification

Environment

• protols version: 0.11.5
  • I have attached the configuration that I am using for protols at the bottom of this description
  • Of note, I configured "scalameta/nvim-metals" to only be enabled for Scala files: ft = { "scala", "sbt" },
• Editor: Neovim NVIM v0.11.1 with LazyVim
• Other LSP servers: metals (Scala), but this could happen with any LSP server sending custom notifications

Root Cause

This is a known limitation of the underlying async-lsp library that protols uses. As documented in async-lsp issue #20, their library doesn't gracefully handle unknown notifications and crashes instead.

Suggested Solutions

Based on the async-lsp maintainer's response, protols could implement a no-op handler (link) - if needed manually implement handlers for common foreign notifications that simply ignore them. For foreign methods (not in lsp-types) wrappers could be added. FWIW, maybe you could simply ignore anything that is not of protols?

Impact

This makes protols unusable in polyglot projects where multiple LSP servers need to run simultaneously, which is a common development scenario.

Workaround

Currently, the only workaround is to use separate editor sessions for different file types, which significantly impacts developer workflow.

Current protols configuration:

return {
  {
    "neovim/nvim-lspconfig",
    opts = {
      servers = {
        -- Configure protols to only handle .proto files
        protols = {
          filetypes = { "proto" },
        },
-- Other server configurations     
    },
  },

  -- Ensure the necessary tools are installed through Mason
  {
    "williamboman/mason.nvim",
    opts = function(_, opts)
      opts.ensure_installed = opts.ensure_installed or {}
      vim.list_extend(opts.ensure_installed, {
        "protols", -- Protobuf support
      })
    end,
  },
}

• I did use justrequire("lspconfig").protols.setup({}) for months before today with the same result...

[asharkhan3101]

#84 should fix this, can you verify it please.

[vasigorc]

Hey @asharkhan3101 That was hyper-quick, thank you! I've installed current version via Mason. In order to test your fix would I have to:

1. Clone the repo
2. git checkout ashar/builder-pattern
3. Run cargo build
4. Copy the binary from the compiled target to ~/.local/share/nvim/mason/packages/protols/bin/
5. Redo my test?

[asharkhan3101]

To test from that branch (assuming proper rust installation)

• Clone this repo
• Switch to that branch and from within project root run
• cargo b --release && mv ./target/release/protols ~/.cargo/bin

Because Mason binary is preferred so you would temporarily remove protols from ensure_installed list and remove the mason installed binary (:Mason from neovim). this would cause neovim to load protols from path next time which would load this new version. After verification you can rollback these changes.

[vasigorc]

Yep, I think that it fixed it @asharkhan3101 ✅

Here is a summary of what I did to test:

1. Forked and cloned your repo
2. Did this (copied from history):

 5963  rustup update nightly
 5964  rustup default nightly
 5965  cargo --version
 5966  cargo b --release
 5970  mv ./target/release/protols ~/.cargo/bin/

3. Checked that protols is now read from ~/.cargo/bin

which protols
${USER_HOME}/.cargo/bin/protols

4. Commented out the ensure install from Mason block
5. :MasonUninstall protols
6. <leader>lS to sync and quit with :qa
7. In my project re-open NeoVim, perform the tasks from the description of the issue. Both Scala's metals and protols co-exist without any conflict 🎉

Thank you very much! When do you think that 0.12.6 could be available via Mason?

[asharkhan3101]

Released on github and on crates.io
Should be available in a few hours. I have done my part now its up to mason's renovate bot to update registries.

[coder3101]

Came here to thank you for such a detailed bug report. It truly helped in the accelerating fix time. 👍🏻