Lua runtime error - LSP -> RPC: no 'is_closing' attribute

[levouh]

Neovim version (nvim -v)

NVIM v0.8.0-dev-980-gefacb6e97 (self-built appimage using Ubuntu 18.04 image)

Vim (not Nvim) behaves the same?

Yes

Operating system/version

Fedora 35

Terminal name/version

N/A

$TERM environment variable

N/A

Installation

appimage (self-built appimage using Ubuntu 18.04 image)

How to reproduce the issue

local client = vim.lsp.buf_get_clients()[1]
client.is_stopping()

Bisected to 126fe7fbc9c88c412c8067d9d146d998baf6dd47 introducing the issue.

CC: @mfussenegger

Expected behavior

No error when calling rpc.is_closing via lsp.is_stopped.

Actual behavior

Error detected while processing InsertEnter Autocommands for "*":                                                                                                                                                                              
E5108: Error executing lua ....mount_nvimfgA6SZ/usr/share/nvim/runtime/lua/vim/lsp.lua:1512: attempt to call field 'is_closing' (a nil value)                                                                                                  
stack traceback:                                                                                                                                                                                                                               
        ....mount_nvimfgA6SZ/usr/share/nvim/runtime/lua/vim/lsp.lua:1512: in function 'is_stopped'                                                                                                                                             
        ...pack/packer/opt/cmp-nvim-lsp/lua/cmp_nvim_lsp/source.lua:16: in function 'is_available'                                                                                                                                             
        ...e/pack/packer/opt/cmp-nvim-lsp/lua/cmp_nvim_lsp/init.lua:57: in function '_on_insert_enter'                                                                                                                                         
        [string ":lua"]:1: in main chunk

[levouh]

I take back part of what I said above - troubleshooting a bit more myself as my bisect is incorrect.

Testing for whether bisect was right was actually incorrect, originally mentioned commit (126fe7fbc9c88c412c8067d9d146d998baf6dd47) is indeed the issue.

[anand-bala]

@levouh are you using any non-nvim-lspconfig plugins like null-ls or something? I have the same issue, and it is because null-ls (for me) hasn't updated to the new layout for client.rpc where there is no handle field.

EDIT: See jose-elias-alvarez/null-ls.nvim#1052

[levouh]

@levouh are you using any non-nvim-lspconfig plugins like null-ls or something? I have the same issue, and it is because null-ls (for me) hasn't updated to the new layout for client.rpc where there is no handle field.

This one is from nvim-cmp-lsp, however I do not see a breaking change tied to the commit that introduced the issue. Can you link me the one you are referring to @anand-bala?

[anand-bala]

So the issue isn't really with nvim-cmp-lsp. That plugin just sets up an autocommand for InsertEnter, which calls a chain of functions that eventually leads to client.is_stopped. For me, the culprit was null-ls which hasn't been updated in 8 days, and hence wasn't able to adapt to the latest nightly 😄 .

[levouh]

So the issue isn't really with nvim-cmp-lsp. That plugin just sets up an autocommand for InsertEnter, which calls a chain of functions that eventually leads to client.is_stopped. For me, the culprit was null-ls which hasn't been updated in 8 days, and hence wasn't able to adapt to the latest nightly 😄 .

I understand that. I'm asking which commit in Neovim introduced the change that now requires other plugins to be updated.

[anand-bala]

I understand that. I'm asking which commit in Neovim introduced the change that now requires other plugins to be updated.

Ah. Sorry, my bad. Your bisect seems to be correct (126fe7fbc9c88c412c8067d9d146d998baf6dd47). Confirmed this by checking out the parent commit, which fixes the issue.

[mfussenegger]

null-ls will need a small change like this:

diff --git a/lua/null-ls/rpc.lua b/lua/null-ls/rpc.lua
index 43a3fe3..12fd0b9 100644
--- a/lua/null-ls/rpc.lua
+++ b/lua/null-ls/rpc.lua
@@ -157,10 +157,16 @@ M.start = function(dispatchers)
             end,
             kill = function()
                 stopped = true
             end,
         },
+        is_closing = function()
+            return stopped
+        end,
+        terminate = function()
+            stopped = true
+        end,
     }
 end

 M.flush = function()
     for uri, notification in pairs(notification_cache) do

[levouh]

So is this a intentional breaking change then @mfussenegger? Should I close this issue?

Should there be a post on ths issue dedicated to breaking changes that calls this out?

Also note the original issue has nothing to do with null-ls, while I imagine the fix is somewhat similar either way.

[mfussenegger]

The change is intentional yes.
The problem is with plugins which monkey-patched rpc.start - which was a bit of a hack.
Using language-servers without stdio was so far not supported and the API that changed was an internal API (although it was documented, users had no sanctioned way to hook into it in a way where changes to it would matter)

Looks like null-ls also patched this already: jose-elias-alvarez/null-ls.nvim@de75168

The good news is that the changes made now no longer make such hacks necessary, and what null-ls does (once it adapts fully, the commit linked above is only the quick-fix) is no longer considered a hack but supported.