Uncaught Error: Header must provide a Content-Length property.

[LaylBongers]

I am not sure how to reproduce this, this seems to happen seemingly randomly when I'm working on code.
When this happens this error will keep repeating until I re-open atom.

Atom: 1.24.0 ia32
Electron: 1.6.16
OS: Microsoft Windows 10 Pro
Thrown From: ide-rust package 0.14.0

Stack Trace

Uncaught Error: Header must provide a Content-Length property.

At C:\Users\Layl\.atom\packages\ide-rust\node_modules\vscode-jsonrpc\lib\messageReader.js:200

Error: Header must provide a Content-Length property.
    at StreamMessageReader.onData (/packages/ide-rust/node_modules/vscode-jsonrpc/lib/messageReader.js:200:27)
    at /packages/ide-rust/node_modules/vscode-jsonrpc/lib/messageReader.js:185:19)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:188:7)
    at readableAddChunk (_stream_readable.js:176:18)
    at Socket.Readable.push (_stream_readable.js:134:10)
    at Pipe.onread (net.js:551:20)

Commands

     -0:45.5.0 intentions:highlight (input.hidden-input)
     -0:45.3.0 core:copy (input.hidden-input)
  2x -0:42 core:backspace (input.hidden-input)
     -0:41 autocomplete-plus:confirm (input.hidden-input)
     -0:40.5.0 intentions:highlight (input.hidden-input)
     -0:40.4.0 core:paste (input.hidden-input)
  2x -0:37.1.0 core:backspace (input.hidden-input)
  2x -0:28.3.0 intentions:highlight (input.hidden-input)
     -0:27.4.0 core:copy (input.hidden-input)
     -0:26.4.0 intentions:highlight (input.hidden-input)
     -0:26.3.0 core:paste (input.hidden-input)
     -0:24.9.0 intentions:highlight (input.hidden-input)
     -0:24.7.0 core:save (input.hidden-input)
  2x -0:23.9.0 core:backspace (input.hidden-input)
     -0:22.5.0 intentions:highlight (input.hidden-input)
     -0:22.4.0 core:save (input.hidden-input)

Non-Core Packages

atom-ide-ui 0.9.2 
file-icons 2.1.17 
file-types 0.5.5 
gruvbox-plus-syntax 1.3.1 
ide-rust 0.14.0 
intentions 1.1.5 
language-cmake 1.1.0 
language-glsl 2.0.4 
language-latex 1.1.1 
language-markedly 0.0.0 
language-openscad 0.4.3 
language-rust 0.4.12 
language-vue 0.23.1 
language-x86-64-assembly 2.2.11 
minimap 4.29.8 
minimap-linter 2.1.3 
pdf-view 0.65.0 

[alexheretic]

This error happens when jsonrpc lib fails to parse a message coming from Rls stdout. It usually means something is printing to stdout, which is fairly easy to do but is deadly to the LSP over stdout. vscode-jsonrpc does not seem able to recover, so as you say you need to restart the language server.

In order to trace what is causing the parse failure, we'd need to know the stdout that caused the failure. Unfortunately the error from jsonrpc does not include this.

If you can reproduce it fairly reliably we can probably trace the issue. Are you getting it on particular projects?

[LaylBongers]

I have not been able to reliably reproduce this issue.
I get it occasionally with a project I have been working on, next time it occurs I'll try to see if I can track down the cause.

[alexheretic]

Yes I was afraid of that, the stdout comms is quite fragile. Anything Rls-side printing can cause this. As most usage is tested, it should only be edge-cases printing and slipping through the test-net.

I'll try to find a way to get the offending stdout into the atom console, that way when it happens we can open the console to see the cause.

[alexheretic]

I just pushed 28e96f8 to try an log an error when dodgy stdout gets pushed down the pipe. So by the next release opening the console should point us in the right direction for these sorts of errors.

[alexheretic]

I just hit one of these caused by rustc printing help output to stdout after a compiler panic. I've raised rust-lang/rust#48816 to see if this can be improved.

Also serves as an example of how the console may look after stdout abuse, logging it as suspicious stdout

[alexheretic]

The instance of this I reproduced will be fixed by rust-lang/rust#48993, which should be in the next nightly release. I'll close this once that's available.

[alexheretic]

This morning nightly 2018-03-14 is available (rust-lang/rust@521d91c), so this issue is addressed until the next time rls prints to stdout ...