Initialize response from LSP Server doesn't reach the (vscode) lsp client (TransportKind is stdio)

[tlaemmlein]

Hi,
I have implemented an LSP server c++ under windows (Visual Studio 2022).
For this I used the https://github.com/kuafuwang/LspCpp repro.
I added this simple C++ server implementation
LspServer.zip
in the https://github.com/kuafuwang/LspCpp/tree/master/examples folder.
This server works with standard input/output (stdio) communication via boost.
Hint: The server logs into DebugOutput. You can fetch this log entries with https://learn.microsoft.com/de-de/sysinternals/downloads/debugview

On the client side I sligthly changed https://github.com/microsoft/vscode-extension-samples/blob/main/lsp-sample/client/src/extension.ts
to

const serverOptions: ServerOptions = {
command:
'C:/Users/laemmleint/lspcpp/_build/Release/LspServer',
};

The aim is that the initialize request/response is working.

Therefore the client sends the init request -> the server gets this request and sends a response back, but the client never get this response.

I added a breakpoint in the client.js file

But the response remains in a endless loop.

The server write the log entries into DebugOutput, and it seems there are no problems with this response:

Furthermore I tested the initialize with
https://github.com/kuafuwang/LspCpp/blob/master/examples/StdIOClientExample.cpp
Here are no problems at all. The C++ client gets the initialize response.

Who can help me in this case?

Regards,

Thomas

[tlaemmlein]

After Investigation some time, I know the whole communication for LSP works with node.js child process (https://nodejs.org/api/child_process.html).

So I added a simple 'child process' code here:

And what a surprise, the breakpoint is working. Hence the response from the server is arriving.

Who can help me to find the code were vscode process the response?
I see the StreamMessageReader and StreamMessageWriter, but I don't know where these classes will be called/triggered.

[tlaemmlein]

Finally I found the problem.
The LSP-Server creates for the header not a \r\n sequence rather the wrong sequence \r\r\n.
Of course it is a bug in the lsp server.
But I found the code where the input (=response) buffer wil be analyzed in the lsp clinet side.
It is the messageReady.js file at this location:

In line 136 there is only a return without an event (like 'this.fireError') about this error. That is one reason why I have problems that I couldn't find the problem in a shorter time.

Furthermore why produce 'tryReadHeaders an error with this \r\r\n sequence?

[dbaeumer]

The onData has now a try/catch block to better discover these errors and report them via the error listener.

The reason why \r\r\n is incorrect is that both http and lsp define header value separators as \r\n

I am closing the issue. Sounds like you found the underlying problem.