search

jose-elias-alvarez / null-ls.nvim

Use Neovim as a language server to inject LSP diagnostics, code actions, and more via Lua.
Other
3.64k stars 791 forks source link

Code Action RPC error #197

Closed vanhtuan0409 closed 3 years ago

vanhtuan0409 commented 3 years ago

FAQ

Issues

Neovim Version

NVIM v0.5.0

Steps to reproduce

  1. Enable null-ls builtin code_actions.gitsign
  2. Trigger Blame line action by calling vim.lsp.buf.code_action()

Note: I have 2 LSP servers attached. 1 is Null-ls, the other is Gopls.

Expected behavior

Action is performed and no error message. Wonder if 2 LSP servers attached is causing issue

Actual behavior

Blame line popup appears but an error message is shown at the status line

2021-09-16_21-55

Debug log

2021-09-16_21-58

Help

No

Implementation help

No response

jose-elias-alvarez commented 3 years ago

I can't reproduce this with the language servers I regularly use (lua-language-server and tsserver). Can you check if it happens with other language servers, too? If not I can try to set up gopls and investigate.

vanhtuan0409 commented 3 years ago

Tested with tsserver and no error shown. Seems like it gopls issue. Tks you anyway :D

vanhtuan0409 commented 3 years ago

Seems like nvim lsp client also sends request to gopls. Gopls then return error because it cannot handle NULLL_LS_CODE_ACTION command.

Do you know a way that we can mitigate this issue or supress the error msg? @jose-elias-alvarez

vanhtuan0409 commented 3 years ago

current builtin behaviour is to send code action command to all attached server. therefore, NULL_LS_CODE_ACTION is accidentally sent to gopls, which answered with an error response. Default lsp handlers will logs any error response if exists https://github.com/neovim/neovim/blob/v0.5.0/runtime/lua/vim/lsp/handlers.lua#L438 can override default workspace/executeCommand to supress error message as follow

local default_exe_handler = vim.lsp.handlers["workspace/executeCommand"]
vim.lsp.handlers["workspace/executeCommand"] = function(err, result, ctx, config)
  -- supress NULL_LS error msg
  local prefix = "NULL_LS"
  if err and err.message:sub(1, #prefix) == prefix then
    return
  end
  return default_exe_handler(err, result, ctx, config)
end

I will close the ticket but leave my workaround here in case anyone need it

jose-elias-alvarez commented 3 years ago

Thank you for looking into this! I'm going to re-open it since I'd like to see if I can improve the behavior (I can see that other servers log an error, which isn't ideal either).

n3wborn commented 3 years ago

Maybe I'm wrong but I've just opened an issue on gitsigns repo today about code_actions not working on nightly. I prefer mentioning it just in case this could be related to this issue.

jose-elias-alvarez commented 3 years ago

@n3wborn I think this is unrelated. Is everything working as expected now?

For the original issue: I looked into this more, and it's pretty tricky, since according to the specification, command is just a string, but servers will either throw or log an error when they receive a request for a command they're unable to handle. We could set command to something that gopls recognizes, but that might cause issues with other servers. This happens when the textDocument/codeAction request is sent in the first place, so there's really no point where we can prevent this from happening (overriding the workspace/executeCommand handler is clever, but it just suppresses the error).

Both lua-language-server and tsserver handle this case by logging the error via this method, and that seems like better behavior from a UX perspective, so I'm going to close this, since I think the only clean fix would be to modify how this error is handled in gopls itself.