Uncaught exception: Header must contain a Content-Length property

[eruizc-dev]

I've been a bit frustrated with this error since months at this point. I can't find a proper way to reproduce and logs do not help: maybe someone here knows better than I do.

This causes the plugin to completely stop working, vim becomes slow and I get a ton of error messages:

CocInfo output:

undefined## versions

vim version: NVIM v0.5.0-828-g0a95549d6
node version: v15.2.1
coc.nvim version: 0.0.79-9eb7e5b2ae
coc.nvim directory: /home/eruizc/.config/nvim/plugged/coc.nvim
term: alacritty
platform: linux

## Log of coc.nvim

2020-12-10T18:16:26.003 INFO (pid:145067) [plugin] - coc.nvim 0.0.79-9eb7e5b2ae initialized with node: v15.2.1 after 354ms
2020-12-10T18:16:27.563 INFO (pid:145067) [language-client-index] - Language server "cs" started with 145137
2020-12-10T18:16:32.974 ERROR (pid:145067) [server] - uncaughtException Error: Header must provide a Content-Length property.
    at StreamMessageReader.onData (/home/eruizc/.config/nvim/plugged/coc.nvim/build/index.js:18138:27)
    at Socket.<anonymous> (/home/eruizc/.config/nvim/plugged/coc.nvim/build/index.js:18123:18)
    at Socket.emit (node:events:329:20)
    at addChunk (node:internal/streams/readable:304:12)
    at readableAddChunk (node:internal/streams/readable:279:9)
    at Socket.Readable.push (node:internal/streams/readable:218:10)
    at Pipe.onStreamRead (node:internal/stream_base_commons:192:23)
## From here the previous exception repeats

After 5 seconds of opening the solution I already have a log with +5000 lines of the previous exception with a difference of 1 to 200 milliseconds between each.

It works fine in some projects (specially small ones) and currently breaks in 2 of my company projects. It used to work originally in both of them but now it's completely dead.

What do these projects share that others do not?

• ASP.NET Core (2.1 and 3.1)
• Private repo
• Uses private nuget packages from github

[eruizc-dev]

After completely ruining my computer today I've fixed it but I have absolutely no idea what could it be... Thins I've done:

• Uninstalled and reinstalled coc-omnisharp (completely)
• Uninstalled all dotnet 3.1.8 tools I had (sdk, runtime, asp...) and installed the 5.0.1
• Deleted the repos that had issues and clone them again
• Installed omnisharp 1.37.3 (1.37.4 doesn't work)

[yatli]

Installed omnisharp 1.37.3 (1.37.4 doesn't work)

Perhaps this. The latest version will not even start...

[yatli]

I really hope the upstream can test the lsp use cases more thoroughly before a release.

[eruizc-dev]

I've tried multiple versions before and it happened with all 1.37.x versions that work. It has to be something else,

[addisonbeck]

I'm seeing this too. The behavior seems to be sporadic, but it makes coc-omnisharp unusable. I'm using .NET 5 and omnisharp 1.37.3.

## versions

vim version: NVIM v0.5.0-dev+c64cce9
node version: v15.2.1
coc.nvim version: 0.0.80-7642d233d6
coc.nvim directory: /Users/addisonbeck/.config/nvim/plugged/coc.nvim
term: iTerm.app
platform: darwin

## Log of coc.nvim

2020-12-28T11:03:29.069 INFO (pid:18198) [services] - registered service "highlight"
2020-12-28T11:03:29.200 INFO (pid:18198) [language-client-index] - highlight started with 18200
2020-12-28T11:03:29.213 INFO (pid:18198) [plugin] - coc.nvim 0.0.80-7642d233d6 initialized with node: v15.2.1 after 413ms
2020-12-28T11:03:29.359 INFO (pid:18198) [language-client-index] - Language server "cs" started with 18203
2020-12-28T11:03:41.907 ERROR (pid:18198) [server] - uncaughtException Error: Header must provide a Content-Length property.
    at StreamMessageReader.onData (/Users/addisonbeck/.config/nvim/plugged/coc.nvim/build/index.js:18074:27)
    at Socket.<anonymous> (/Users/addisonbeck/.config/nvim/plugged/coc.nvim/build/index.js:18059:18)
    at Socket.emit (node:events:329:20)
    at addChunk (node:internal/streams/readable:304:12)
    at readableAddChunk (node:internal/streams/readable:279:9)
    at Socket.Readable.push (node:internal/streams/readable:218:10)
    at Pipe.onStreamRead (node:internal/stream_base_commons:192:23)

EDIT: Looks like for me deleting and recloning the project fixed the issue, though I have no idea why.

EDIT AGAIN: Nevermind, things were working normally for a few minutes and then broke again.

[eruizc-dev]

I can relate to what addison said. The issue occurs in some projects, but not others. Sometimes deleting and recloning the project fixes it, sometimes it doesn't. Sometimes updating reated plugins solves it, sometimes it breaks it even more...

It's extremely spontaneous.

[puuuuh]

I thinks its bug in omnisharp. It print some errors in stdout. For me its Can't find custom attr constructor image: {some path}/bin/Debug/net5.0/Core.dll mtoken: 0x0a000001 due to: Cannot resolve dependency to assembly because it has not been preloaded. When using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or loaded on demand through the ReflectionOnlyAssemblyResolve event.

Probably its related to https://github.com/OmniSharp/omnisharp-vim/issues/631 and https://github.com/OmniSharp/omnisharp-roslyn/issues/1942

[sistemd]

Also running into this error. Started happening out of nowhere, with no change in configuration. I was using omnisharp-vim before I switched to coc-omnisharp, and I never got this error. Switching back, and still, I am not getting the error with omnisharp-vim.

[sistemd]

But it seems to me that even though this error is happening, code completion continues to work. It is really hard to use it because the error keeps popping at the bottom of my editor. Is it perhaps possible to simply suppress the error somehow, and see what happens?

[raymonddavis]

@ennmichael I just encountered this and fixed mine by running dotnet clean. Seems it is picking up the build dlls maybe?

[addisonbeck]

Thank you, cleaning between builds has fixed this for me too. That seems like the answer. Is ignoring build files possible from the plugin?

[prescottbreeden]

dotnet clean removed the error from spawning during the running session, however it doesn't fix the problem that you have no intellisense because there was no connection established to the language server. Looking at the code, I don't see anywhere this package can fix the issue of not providing proper headers required by the language server API.

[ProgrammingLife]

The same problem. I can't fix this issue. I've done with:

• cloning coc git
• dotnet clean
• removed plugged folder, removed ~/.config/coc/ and installed all those plugins again

absolutely no success. As somene said above, it started happening out of nowhere, with no change in configuration. What to do?

[ProgrammingLife]

I've fixed this with some strange solution. As it happened with the Unity project I've done this: rm MyUnityProject/obj/Debug/* There are two project .cache-files. After that my coc-omnisharp seems to be working now but how much time it will work - I don't know. VSCode had been loading that "broken" project without any problems. Maybe it's not a broken project but some file format that coc-omnisharp can't read properly.

[lbergnehr]

I have a similar workaround as @ProgrammingLife in that I quit Vim, then run dotnet clean and then start Vim again. That seems to be pretty reliable and I can then dotnet build without coc in that Vim session breaking.

[cjayross]

+1 This is plugin is effectively useless so long as this issue exists. Have the devs abandoned this repo?

[thomazmoura]

I have a similar workaround as @ProgrammingLife in that I quit Vim, then run dotnet clean and then start Vim again. That seems to be pretty reliable and I can then dotnet build without coc in that Vim session breaking.

No need to restart VIM - as long as you do a dotnet clean and run :CocRestart it will work. I've even put on my .vimrc as a shortcut (<leader> + R) to be able to quickly do it whenever I open a new .NET project:

nnoremap <Leader>R :!dotnet clean<CR>:CocRestart<CR>

But it's still only a workaround. It would really help if this could be fixed - I've searched a bit and I do believe this is related to using stdio as protocol instead of http, but I relly couldn't dig enough to test it with http (and apparently stdio was supposed to be better than http for that).