update from 3.0.4/3.0.5 to 3.1.0 breaks my extension

[siegebell]

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]

Just tried vscode 1.10.1 and see the same issue.

[dbaeumer]

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]

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]

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

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

[siegebell]

"--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]

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]

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

[siegebell]

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]

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