Show message to the user in case of language server starting error

[robertoaloi]

Starting a language server via a client.start() can result in an error. Usually the stdout or stderr for the server process contain hints to what the problem could be. In case of such an error while starting the server, the only message displayed to the user is something like:

[Error - 1:33:53 PM] Connection to server got closed. Server will not be restarted.

I wonder if there's any way to improve the situation and display the stdout/stderr from the server to the user when the language server fails to start. The clientOptions include a errorHandler that can be customized, but that doesn't seem to help, since when the issue occurs the closed() method does not get any arguments.

Note: I'm not a Typescript / JS developer myself, so there may be something I'm missing.

[dbaeumer]

If the communication channel is NOT stdout/stdin then everything a server write to stdout/stderr is printed to the output channel. The corresponding code is here:

vscode-languageserver-node/client/src/node/main.ts

Line 341 in f271aef

serverProcess.stderr.on('data', data => this.outputChannel.append(Is.string(data) ? data : data.toString(encoding)));

So in your case it looks like the server doesn't start and even capturing stderr/stdout doesn't work.

[robertoaloi]

The communication channel does use stdout/stdin (code at https://github.com/erlang-ls/vscode/blob/main/client/src/extension.ts#L19 and https://github.com/erlang-ls/vscode/blob/main/client/src/client.ts#L46). As a language server maintainer, what I'm trying to figure out is how can I improve things in the VS Code client so that eventual issues which cause the server to fail to start (e.g. due to environmental issues) can be propagated to the user via the UI.

[dbaeumer]

If the communication happens over stderr / stdout the server can't use these to write message to the console. It will interfere with the communication.

The protocol defines alternative message which work in all cases. See https://microsoft.github.io/language-server-protocol/specifications/specification-3-17/#window_logMessage

[alanz]

I think Roberto is talking about a scenario where the server is misconfigured, and fails to start.

At the moment you just get an error saying the server did not start, and eventually reports 5 failures and stops.

Perhaps we could have an option when that point is reached to display whatever the server did emit on stdout/stderr somewhere on the client.

[robertoaloi]

Alan's interpretation is correct. I'm raising this with the Emacs LSP client as well.

[alanz]

FYI, rust-analyzer does a message pop-up on error starting up

https://github.com/rust-analyzer/rust-analyzer/blob/7d1015b8d177a02dff03d2c70bc74e5d4ed34335/editors/code/src/main.ts#L19-L26

[robertoaloi]

@alanz That looks promising. I can try and port that to our server. If that works it's probably worth implementing something similar in the client or, at least, in the LSP sample extension.

[dbaeumer]

@robertoaloi so in our case the process creation fails. Right? What kind of server do you have and how do you start it.

[robertoaloi]

@dbaeumer The process is an external executable, implemented in Erlang. You can see the start code here:

https://github.com/erlang-ls/vscode/blob/main/client/src/extension.ts#L14-L20

https://github.com/erlang-ls/vscode/blob/main/client/src/client.ts#L13

[robertoaloi]

Here is a workaround for this issue in Erlang LS: erlang-ls/vscode#114

[dbaeumer]

The handler now allows to return a message that will be presented to the user with a button to open the output channel (which contains stdout)

[robertoaloi]

That's nice. Will try this asap, thanks!

[axelson]

The handler now allows to return a message that will be presented to the user with a button to open the output channel (which contains stdout)

That's great! Are there any examples of a client that utilizes it?

[dbaeumer]

The LSP client itself uses it :-). Search for references.