Error NO_RESULT_CALLBACK_FOUND with Neovim's native LSP

[dtomvan]

rust-analyzer version: rust-analyzer ad6810e 2022-06-06 stable

rustc version: rustc 1.62.0-nightly (f4a7ce997 2022-04-08)

neovim version: NVIM v0.8.0-dev 37ee800b519

relevant settings:

CARGO_HOME=/home/tomvd/.local/share/cargo
RUSTUP_HOME=/home/tomvd/.local/share/rustup

Neovim LSP config is done with https://github.com/simrat39/rust-tools.nvim and https://github.com/williamboman/nvim-lsp-installer

Link to (very long) log: https://www.toptal.com/developers/hastebin/ihiguxinej.properties

Ref: neovim/neovim#15844
The above issue told me that the issue is with the language server, not with neovim itself.

[ten3roberts]

This issue is reprocucible with the default

require"lspconfig".rust_analyzer.setup {}

[flodiebold]

neovim/nvim-lspconfig#225 says the configs there are "best-effort" and unsupported. I don't see anything saying that it's a server issue. The log seems to just be a completion response. If there are some specific steps that lead to the error, it would help if you could name them, and see whether they lead to similar errors with other clients (VSCode, Emacs, ...). If the issue does not happen with older rust-analyzer versions, that would also be interesting. Otherwise I would suggest asking at nvim-lspconfig or rust-tools.nvim.

[dtomvan]

neovim/nvim-lspconfig#225 says the configs there are "best-effort" and unsupported. I don't see anything saying that it's a server issue. The log seems to just be a completion response. If there are some specific steps that lead to the error, it would help if you could name them, and see whether they lead to similar errors with other clients (VSCode, Emacs, ...). If the issue does not happen with older rust-analyzer versions, that would also be interesting. Otherwise I would suggest asking at nvim-lspconfig or rust-tools.nvim.

This error just occurs when typing things (at random moments). I have no idea where the issue may be coming from. I'll try without rust-tools.nvim, and on Emacs, to see if it is any issue with rust-analyzer, or with the Neovim LSP config.

I think the issue started coming up when upgrading from rust-analyzer 2022-06-06 (system installation on Arch Linux) to the one used by nvim-lsp-installer, which is the version in my previous comment.

Edit: I won't need to check if it works without rust-tools, as that has been checked by ten3roberts.

[dtomvan]

Update: This doesn't occur on Emacs, so I think this issue is nvim-lspconfig specific. Using the normal (non-lsp-installer) version of rust-analyzer doesn't help. I did update from lspconfig version 84252b0 to eb03999, but downgrading back doesn't help either. I guess this issue just started appearing all of a sudden, which I find weird.

[dtomvan]

Another update: (I'm sorry for the spam) The latest version (package in Arch Linux's community repo) I can find not to error is rust-analyzer 2022-05-30. I guess it is some breaking change in rust-analyzer, then.

[ten3roberts]

I downgraded from the 2022-06-06 to 2022-05-30 and everything works perfectly.

[Kangaxx-0]

Same issue after upgrading rust_analyzer with version 2022-06-06

[flodiebold]

If someone could bisect the issue to a specific commit in that range, that would be helpful.

[jonhoo]

@flodiebold I'll give that a shot — stay tuned!

[jonhoo]

e2da967 is the first bad commit, so #12431 (cc @Veykril)

Here's one particularly short error I get a fair amount, if it helps:

LSP[rust_analyzer]: Error NO_RESULT_CALLBACK_FOUND: {
  id = 19,
  jsonrpc = "2.0",
  result = {
    isIncomplete = true,
    items = {}
  }

[Veykril]

Hmm, I can only make an assumption here but I imagine that nvim discards requests of a certain kind it sent out if a newer one has been answered. That is if we have requests like completion:id the following might now be happening:

nvim request completion:0
r-a starts processing
nvim request completion:1
r-a cancels completion:0 and requeues it, starts processing completion:1
r-a response completion:1
nvim acknowledges, discards all completion callbacks for ids <= 1
r-a response completion:0
nvim can't find a completion callback for id 0 and errors

This is might seem odd for r-a to do, but to my knowledge the LSP permits this kind of processing. it specifically states that each request has to be replied to, but not in what order.

Though again, this is a wild guess, I do not know how nvim's lsp implementation works, but if this is the case I would argue that this is an implementation error on nvim's side (even if we try to fix the ordering here).

[jonhoo]

@justinmk would love your input here in trying to figure out if this is a rust-analyzer LSP bug, or a bug/missing feature on the neovim LSP side of things. Does what Veykril outlined above match the actual behavior of neovim?

[toothlesslizard]

:LspInstall rust_analyzer@2022-05-30

but i ve got RPC Error sometimes, only RUST related.

[justinmk]

This is might seem odd for r-a to do, but to my knowledge the LSP permits this kind of processing. it specifically states that each request has to be replied to, but not in what order.

@Veykril thanks for that analysis. If someone can open a new Nvim issue I have reopened neovim/neovim#15844

Related Nvim LSP client code: https://github.com/neovim/neovim/blob/4d9e2247c939a5df0a79a06f37ab882ff66aeb01/runtime/lua/vim/lsp/rpc.lua#L554

How do other LSP clients handle this? Just ignore it?

neovim/nvim-lspconfig#225 says the configs there are "best-effort" and unsupported

nvim-lspconfig is just configs, it is not the Nvim LSP client.

[Veykril]

How do other LSP clients handle this? Just ignore it?

There isn't really anything to ignore here, when a reply comes in a client should only mark the request that belongs to that reply as resolved. "Resolving" multiple requests from one reply and then expecting no replies for the other requests to come in won't work as per spec the server should reply to every request in some form.

[justinmk]

I have reopened neovim/neovim#15844 and pasted the helpful comments from here.

[JojiiOfficial]

I'm getting this error on 2022-05-30 as well (but seems to be less frequently)

[mfussenegger]

but I imagine that nvim discards requests of a certain kind it sent out if a newer one has been answered.

Neovim doesn't do that. It clears callbacks only for a given id.
The logs shared in neovim/neovim#15844 indicate that the server is sending multiple responses with the same request id

[Veykril]

We'll need to see some neovim logs for r-a here then, because there isn't really a way for r-a to send multiple responses for one request from what I can see (so I'd like to get proven wrong here then).

[dtomvan]

I have reopened neovim/neovim#15844 and pasted the helpful comments from here.

Does this mean we don't need to keep this issue around, or do we keep conversation in this repo?

[dtomvan]

We'll need to see some neovim logs for r-a here then, because there isn't really a way for r-a to send multiple responses for one request from what I can see (so I'd like to get proven wrong here then).

While trying to look for my lsp log ~/.cache/nvim/lsp.log I couldn't find any logs after 2022-05-23. Which is weird, because I've tried to reproduce this issue 4 days ago, so I'd at least see some logs on 2022-06-06, right?

Anyways, if anyone knows where to find (the proper) logs for nvim LSP that would be appreciated.

[MultisampledNight]

Hm, that actually are the proper logs (opened through :LspLog). Here's my relevant log if that's interesting in any way, for me it looks nonsensical: https://gist.github.com/MultisampledNight/7069f686b2d6b8755c5d6448a1f5d80d

I guess for now it boils down to working without LSP stuff.

[Veykril]

Regarding logs, we'll need one that shows some more LSP calls prior to the error so we can tell what the server and client exchange that causes the problem.

[sapphire-arches]

I grabbed some logs from the rust-analyzer side as well, see my comment here: neovim/neovim#15844 (comment)

Those logs were with RA_LOG=info,rust_analyzer=debug,ide_db=debug,hir_ty=error,chalk_recursive=error,salsa=error

Poking through it with no real experience on r-a or the neovim LSP, my guess is that the problem is related to this line:

[DEBUG rust_analyzer::main_loop] will prime caches cause=restart after cancellation

If anyone wants to reproduce the problem and is familiar with Nix, I've been using this tree to reproduce the problem. Add a line after this one with the contents ctx. and wait for completion to trigger. I can also grab some more detailed logs if that would be helpful.

[Veykril]

Hmm, so I think what might be happening here is that the client cancels the completion request, we acknowledge that but still return a response.

Edit: yep that's it, found the problem I think

[Veykril]

#12508 should fix this, we were resetting the cancelled state of requests when retrying them which made us reply for already cancelled requests again.

[Veykril]

With that said @justinmk you can probably close the issue on the neovim side again as this was a fault on our part after all. Sorry for that!

[sapphire-arches]

I built a r-a based on the branch for #12508 and the problem appears fixed, thanks for the quick turnaround Veykril!

[garrettmaring]

Don't forget to :LspRestart after updating