Erlang LS shut down by VSCode due to Content-Length issue when trying to display signature for io:format(...)

[rvangraan]

Describe the bug
The erlang_ls language server terminates in VS Code when it tries to expand io:format(

[Error - 11:50:13] Connection to server is erroring. Shutting down server.

Erlang LS debug logs

io_format_debug.log.txt

Extension logs from VS Code:

2024-03-19 12:08:47.139 [error] Error: Header must provide a Content-Length property.
    at StreamMessageReader.onData (/Users/rvg.work/.vscode/extensions/erlang-ls.erlang-ls-0.0.42/client/node_modules/vscode-jsonrpc/lib/common/messageReader.js:138:27)
    at Socket.<anonymous> (/Users/rvg.work/.vscode/extensions/erlang-ls.erlang-ls-0.0.42/client/node_modules/vscode-jsonrpc/lib/common/messageReader.js:122:18)
    at Socket.emit (node:events:514:28)
    at addChunk (node:internal/streams/readable:324:12)
    at readableAddChunk (node:internal/streams/readable:297:9)
    at Socket.push (node:internal/streams/readable:234:10)
    at Pipe.onStreamRead (node:internal/stream_base_commons:190:23)
2024-03-19 12:08:47.141 [error] Error: Header must provide a Content-Length property.
    at StreamMessageReader.onData (/Users/rvg.work/.vscode/extensions/erlang-ls.erlang-ls-0.0.42/client/node_modules/vscode-jsonrpc/lib/common/messageReader.js:138:27)
    at Socket.<anonymous> (/Users/rvg.work/.vscode/extensions/erlang-ls.erlang-ls-0.0.42/client/node_modules/vscode-jsonrpc/lib/common/messageReader.js:122:18)
    at Socket.emit (node:events:514:28)
    at addChunk (node:internal/streams/readable:324:12)
    at readableAddChunk (node:internal/streams/readable:297:9)
    at Socket.push (node:internal/streams/readable:234:10)
    at Pipe.onStreamRead (node:internal/stream_base_commons:190:23)
2024-03-19 12:08:47.193 [error] Error: Header must provide a Content-Length property.
    at StreamMessageReader.onData (/Users/rvg.work/.vscode/extensions/erlang-ls.erlang-ls-0.0.42/client/node_modules/vscode-jsonrpc/lib/common/messageReader.js:138:27)
    at Socket.<anonymous> (/Users/rvg.work/.vscode/extensions/erlang-ls.erlang-ls-0.0.42/client/node_modules/vscode-jsonrpc/lib/common/messageReader.js:122:18)
    at Socket.emit (node:events:514:28)
    at addChunk (node:internal/streams/readable:324:12)
    at readableAddChunk (node:internal/streams/readable:297:9)
    at Socket.push (node:internal/streams/readable:234:10)
    at Pipe.onStreamRead (node:internal/stream_base_commons:190:23)
2024-03-19 12:08:47.193 [error] Error: Header must provide a Content-Length property.
    at StreamMessageReader.onData (/Users/rvg.work/.vscode/extensions/erlang-ls.erlang-ls-0.0.42/client/node_modules/vscode-jsonrpc/lib/common/messageReader.js:138:27)
    at Socket.<anonymous> (/Users/rvg.work/.vscode/extensions/erlang-ls.erlang-ls-0.0.42/client/node_modules/vscode-jsonrpc/lib/common/messageReader.js:122:18)
    at Socket.emit (node:events:514:28)
    at addChunk (node:internal/streams/readable:324:12)
    at readableAddChunk (node:internal/streams/readable:297:9)
    at Socket.push (node:internal/streams/readable:234:10)
    at Pipe.onStreamRead (node:internal/stream_base_commons:190:23)

Context

erlang_ls -v
Version: 0.51.0+build.1973.ref97ac6df

Visual Studio Code:

Version: 1.87.2
Commit: 863d2581ecda6849923a2118d93a088b0745d9d6
Date: 2024-03-08T15:20:57.520Z (1 wk ago)
Electron: 27.3.2
ElectronBuildId: 26836302
Chromium: 118.0.5993.159
Node.js: 18.17.1
V8: 11.8.172.18-electron.0
OS: Darwin arm64 23.4.0

[the-mikedavis]

I also ran into this. The JSON returned for a signature help or completionItem/resolve request about io:format/2,3 or io:fwrite/3's docs includes an incorrectly encoded UTF-8 codepoint when rendering this line in particular https://github.com/erlang/otp/blob/2a253c24b870c9334e536256597dd740874909ff/lib/stdlib/src/io.erl#L979. I see the server encoding that character as two characters U+00d0 and U+0080 though it should be U+0400 (hex d0 80 in the UTF-8 representation). I didn't manage to find where the incorrect encoding is coming from but the binary for that code block in the OTP26 edoc chunk for io:fwrite/3 is encoding the character correctly, so at least we can rule out OTP:

<<56,62,32,105,111,58,102,119,114,105,116,101,40,34,126,112,126,110,34,44,91,108,105,115,116,95,116,111,95,97,116,111,109,40,91,49,48,50,52,93,41,93,41,46,10,39,92,120,123,52,48,48,125,39,10,111,107,10,57,62,32,105,111,58,102,119,114,105,116,101,40,34,126,116,112,126,110,34,44,91,108,105,115,116,95,116,111,95,97,116,111,109,40,91,49,48,50,52,93,41,93,41,46,10,39,208,128,39,10,111,107>>

(Ѐ is the 208,128 bytes near the end)