You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I encountered an issue with my language server stalling after sending an applyEdit request to the client from inside of the processing of an executeCommand request. I believe this is a common pattern (code actions give the client command names, client calls executeCommand for the selected action, in the executeCommand we compute the edit and call applyEdit).
The server ends up infinitely waiting in jsonrpc2/conn.go:118 on the response to the applyEdit.
Thus, this issue might actually belong to jsonrpc2 (or of course be me not using either of the packages right).
I am testing mostly using Neovim, and in Neovim's log (~/.cache/nvim/lsp.log) the requests and responses all look appropriate (until my stalled language server stops participating, after sending applyEdit).
I have implemented a minimal working example (see below) that shows the behavior.
I have also implemented a similar small example in Rust using tower-lsp, which works as expected.
Repro
compile the code below, of course
set up with editor (I used Neovim) as client
open any document with the filetype that starts the server, etc.
invoke code action (you should see Foo)
select Foo code action
it properly (calls executeCommand, which calls applyEdit, which) inserts 'FOO'
the client's response to the applyEdit is never received by the server, forever waiting on case resp := <-rchan
Maybe to ask the alternative question: Is the idea of the library that requests to the client need to be run in separate goroutines?
For notifications of course it's fine, but from what I can tell for requests such as applyEdit no separate goroutine is started and then we block in the request (as I describe above) waiting for a message on a channel that won't be sent until we receive it (i.E. deadlock).
The log does seem to indicate the response to applyEdit is sent back (last line). FYI, I found a bug[1] in the unmarshalling of the result of applyEdit so it may be related but I'm not sure.
Another possible avenue for debugging this is to try to use lsp.NewServer. This wraps lsp.ServerHandler with a couple of other handlers (CancelHandler, AsyncHandler and ReplyHandler). This is what I've done, and it worked for me.
I encountered an issue with my language server stalling after sending an
applyEdit
request to the client from inside of the processing of anexecuteCommand
request. I believe this is a common pattern (code actions give the client command names, client calls executeCommand for the selected action, in the executeCommand we compute the edit and call applyEdit).The server ends up infinitely waiting in
jsonrpc2/conn.go:118
on the response to theapplyEdit
.Thus, this issue might actually belong to jsonrpc2 (or of course be me not using either of the packages right).
I am testing mostly using Neovim, and in Neovim's log (
~/.cache/nvim/lsp.log
) the requests and responses all look appropriate (until my stalled language server stops participating, after sendingapplyEdit
).I have implemented a minimal working example (see below) that shows the behavior.
I have also implemented a similar small example in Rust using tower-lsp, which works as expected.
Repro
Foo
)Foo
code actioncase resp := <-rchan
MWE
full main.go
Log
lsp.log snippet
The text was updated successfully, but these errors were encountered: