Version 0.23 breaks NeoVim integration

[datanoise]

Description

While typing Neovim sends incomplete code to ruby-lsp which results in errors like this:

[ERROR][2025-01-07 12:37:03] ...m/lsp/client.lua:1041 "LSP[ruby_lsp]" "on_error" { code = "NO_RESULT_CALLBACK_FOUND", err = { id = 16, jsonrpc = "2.0", result = { items = { { message = "unexpected end-of-input, assuming it is closing the parent top level context", range = { ["end"] = { character = 0, line = 160 }, start = { character = 3, line = 159 } }, severity = 1, source = "Prism" }, { message = "expected anendto close theclassstatement", range = { ["end"] = { character = 0, line = 160 }, start = { character = 0, line = 160 } }, severity = 1, source = "Prism" }, { message = "mismatched indentations at 'end' with 'if' at 71", range = { ["end"] = { character = 5, line = 80 }, start = { character = 2, line = 80 } }, severity = 2, source = "Prism" }, { message = "mismatched indentations at 'end' with 'def' at 70", range = { ["end"] = { character = 3, line = 159 }, start = { character = 0, line = 159 } }, severity = 2, source = "Prism" } }, kind = "full" } } }

It is impossible to type now, because it seems these errors pop up on each key stroke. Reverting to version 0.22.1 fixes the issue.

[vinistock]

Thanks for the report. Is there any other output?

Looking at the snippet you shared, it looks like there's part of an error and part of a syntax error diagnostic. We didn't change anything related to syntax error diagnostics and that has been implemented for a long time, so I assume there's some other error happening there.

[datanoise]

Preceding this log entry there was:

[ERROR][2025-01-07 12:37:03] .../vim/lsp/rpc.lua:484 "No callback found for server response id 16"

Not sure if it helps. All I know is that reverting back to prior version fixes the issue. No configuration changes in my NeoVim config.

[nerdrew]

I'm getting the same errors, but it is for lots of different codes.

.../vim/lsp/rpc.lua:515	"No callback found for server response id 67"
...m/lsp/client.lua:974	"LSP[ruby_lsp]"	"on_error"	{  code = "NO_RESULT_CALLBACK_FOUND",  err = {    id = 67,
.../vim/lsp/rpc.lua:515	"No callback found for server response id 70"
...m/lsp/client.lua:974	"LSP[ruby_lsp]"	"on_error"	{  code = "NO_RESULT_CALLBACK_FOUND",  err = {    id = 70,
.../vim/lsp/rpc.lua:515	"No callback found for server response id 73"
...m/lsp/client.lua:974	"LSP[ruby_lsp]"	"on_error"	{  code = "NO_RESULT_CALLBACK_FOUND",  err = {    id = 73,
LSP logging initiated
.../vim/lsp/rpc.lua:515	"No callback found for server response id 32"
.../vim/lsp/rpc.lua:515	"No callback found for server response id 34"
...m/lsp/client.lua:974	"LSP[ruby_lsp]"	"on_error"	{  code = "NO_RESULT_CALLBACK_FOUND",  err = {    id = 32,
...m/lsp/client.lua:974	"LSP[ruby_lsp]"	"on_error"	{  code = "NO_RESULT_CALLBACK_FOUND",  err = {    id = 34,
.../vim/lsp/rpc.lua:515	"No callback found for server response id 39"
...m/lsp/client.lua:974	"LSP[ruby_lsp]"	"on_error"	{  code = "NO_RESULT_CALLBACK_FOUND",  err = {    id = 39,
LSP logging initiated
.../vim/lsp/rpc.lua:515	"No callback found for server response id 16"
...m/lsp/client.lua:974	"LSP[ruby_lsp]"	"on_error"	{  code = "NO_RESULT_CALLBACK_FOUND",  err = {    id = 16,
.../vim/lsp/rpc.lua:515	"No callback found for server response id 42"
...m/lsp/client.lua:974	"LSP[ruby_lsp]"	"on_error"	{  code = "NO_RESULT_CALLBACK_FOUND",  err = {    id = 42,
.../vim/lsp/rpc.lua:515	"No callback found for server response id 44"
...m/lsp/client.lua:974	"LSP[ruby_lsp]"	"on_error"	{  code = "NO_RESULT_CALLBACK_FOUND",  err = {    id = 44,

This looks similar to this which points to a bug in another LSP server here...

[vinistock]

Thank you for sharing that issue, it's very helpful. Could either of you try something?

If you edit the LSP code in place (BUNDLE_GEMFILE=.ruby-lsp/Gemfile bundle open) and remove this line, does the issue go away?

Reading through those threads, what I understood is that a request cancelled by the client successfully has to continue returning the special cancelled error code even if the client decides to retry the cancelled request, but I want to be sure.

[datanoise]

No change for me. the same errors are being reported.

[datanoise]

But commenting out the prior send_message seems to fix it for me.

[adam12]

Assuming Neovim 0.10.3? There were a few LSP changes made.

• lsp: Retrigger diagnostics request on server cancellation (fix(lsp): retrigger diagnostics request on server cancellation neovim/neovim#31345) (fix(lsp): retrigger diagnostics request on server cancellation (#31345) neovim/neovim#31427)
• lsp: Cancel pending requests before refreshing (fix(lsp): cancel pending requests before refreshing neovim/neovim#31500)

I noticed the same errors yesterday but only once, and didn't have time to look.

[vinistock]

But commenting out the prior send_message seems to fix it for me.

That might cause things to hang, because then the server is receiving a request, but not responding back with anything.

I'm a bit confused with what is expected here. The spec says that the server has to return something, even for cancelled requests - and it mentions that the server should return the request cancelled error code. The spec does not mention anything about cancelled requests being retried or what to do then.

Currently, if we receive the same request a second time after being cancelled, we "forget" that it was cancelled and actually go through with computing it, returning a response. I expected that not deleting it from the list of cancelled requests would fix it, because then instead of returning a response, we would simply continue returning the special error code.

[datanoise]

I am testing it with this send_message removed and I don't see any issues so far. I am not familiar with NeoVim Lsp implementation, but it looks like it doesn't expect any response to canceled requests. It probably removes any references to them and when the server responds to them, it just blows up with the NO_RESULT_CALLBACK_FOUND error into the user face.

[vinistock]

If someone could give the changes in #3021 a try, that would be really helpful. I tried to dig into what Rust Analyzer does and my understanding is that cancelled requests are simply ignored.

[SamSaffron]

just tried it and no luck, I confirm that commenting out the sendmessage above is resolving it though, even on the branch