pommicket opened this issue
Dec 25, 2022
· 3 comments
Labels
goplsIssues related to the Go language server, gopls.NeedsFixThe path to resolution is known, but the work has not been done.ToolsThis label describes issues relating to any tools in the x/tools repository.
This is (as far as I'm aware) a perfectly valid series of LSP requests. (By the time the initialized notification is sent,
the server has already sent the initialize response.)
There should be no problems for gopls here.
What did you see instead?
After the 3rd message, gopls gives the client these notifications:
{"jsonrpc":"2.0","method":"window/showMessage","params":{"type":4,"message":"Loading packages..."}}
{"jsonrpc":"2.0","method":"window/showMessage","params":{"type":3,"message":"Error loading packages: addView called before server initialized"}}
{"jsonrpc":"2.0","method":"window/showMessage","params":{"type":1,"message":"Error loading workspace folders (expected 1, got 0)\nfailed to load view for file:///tmp: addView called before server initialized\n"}}
Using workspaceFolders instead of rootUri gives the exact same result (in any case both must be handled by an LSP server).
Waiting for more time after sending initialized does not resolve the issue.
Sending any more requests after this gives back the cryptic response:
{"jsonrpc":"2.0","error":{"code":0,"message":"no views in session"},"id":...}
with the non-existent error code 0.
The text was updated successfully, but these errors were encountered:
gopherbot
added
Tools
This label describes issues relating to any tools in the x/tools repository.
gopls
Issues related to the Go language server, gopls.
labels
Dec 25, 2022
I can repro, and will investigate. Thank you for the script. My guess is that it is the lack of workspace folders that causes this script to fail, but I'm surprised that this wouldn't have been reported before now (I verified that this bug exists at least back to gopls@v0.7.5.
I can repro, and will investigate. Thank you for the script. My guess is that it is the lack of workspace folders that causes this script to fail, but I'm surprised that this wouldn't have been reported before now (I verified that this bug exists at least back to gopls@v0.7.5.
How did you first encounter this?
I encounter the same bug with a LSP plugin for the vis editor, I maintain.
The LSP client for the vis editor has no sense of LSP workspaces.
But since I had no easy reproducer I did not open an issue yet.
However, I am very happy that @pommicket did :)
Ok, I investigated and the bug is actually that the initialized notification is never processed, because parsing params fails as a result of the params field missing. If you add "params": {} to the initialized notification, it works.
goplsIssues related to the Go language server, gopls.NeedsFixThe path to resolution is known, but the work has not been done.ToolsThis label describes issues relating to any tools in the x/tools repository.
4 participants
You can’t perform that action at this time.
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.
gopls version
What did you do?
Here is a simple "virtual" LSP client:
What did you expect to see?
This is (as far as I'm aware) a perfectly valid series of LSP requests. (By the time the
initialized
notification is sent,the server has already sent the
initialize
response.)There should be no problems for gopls here.
What did you see instead?
After the 3rd message, gopls gives the client these notifications:
Using
workspaceFolders
instead ofrootUri
gives the exact same result (in any case both must be handled by an LSP server).Waiting for more time after sending
initialized
does not resolve the issue.Sending any more requests after this gives back the cryptic response:
with the non-existent error code 0.
The text was updated successfully, but these errors were encountered: