microsoft/vscode-languageserver-node

update from 3.0.4/3.0.5 to 3.1.0 breaks my extension

siegebell opened this issue · 9 comments

siegebell commented

When I update vscode-languageclient and vscode-languageserver from 3.0.5/3.0.5 to 3.1.0, my language server stops loading. I've tried to minimize the server to just printing something to the connection's log in onInitialize, but the server never seems to load, I cannot attach a debugger to the server, and the client never reports that the server is ready.

platform: Windows 8.1 64bit
vscode: 1.10.0-insider 40fecfaa77f01672e8a147be71f7ccb9cf8a12, and 1.9.1 release
vscode-jsonrpc: I've tried both 3.0.4 and 3.1.0

siegebell commented

Just tried vscode 1.10.1 and see the same issue.

dbaeumer commented

Bad :-).

I tried this in my test beds and there it works. Do you have a repository I can clone to see what is happening?

What transport are you using ?

dbaeumer commented

If the server is a node server you can change the debug options to something like this:

let debugOptions = { execArgv: ["--nolazy", "--debug-brk=6012"] };

This start the server in break mode and lets you debug the initialize call as well.

dbaeumer commented

I also upgraded https://github.com/Microsoft/vscode-languageserver-node-example to use 3.1.0 and it works for me without a problem.

@siegebell any additional information you can provide. Does the above example work for you?

siegebell commented

"--debug-brk=6012" does not help; the debugger is still not able to connect.

I've also tried both legacy and inspector protocols.

Edit: I also made sure that the debugging port numbers match and have tried telling LanguageClient to force debug.

siegebell commented

Not sure if this is related, but the extension's debug console shows "rejected promise not handled within 1 second", which might be server.onReady() failing. Speaking of which, neither catch nor then are triggering for server.onReady().

dbaeumer commented

@siegebell can you share the project. Since this works in all of my setup it is hard to tell what could go wrong.

siegebell commented

I've solved the issue! It seems that the transport default was changed in 3.1.0.

Client: I did not specify the transport kind.
Server: I called createConnection(process.stdin, process.stdout)

Fix: either specify TransportKind.stdio in the client or else call createConnection() (without arguments) in the server.

So if there's any bug to report, it could be to note the breaking change with the 3.1.0 release and to have the client report an error if it detects that the server is using a different transport protocol.

dbaeumer commented

@siegebell thanks for tracking this down. This is definitely a bug and shouldn't have happened. Let me fix this again.