coc-omnisharp: Uncaught exception: Header must contain a Content-Length property

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:

image

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

About this issue

  • Original URL
  • State: open
  • Created 4 years ago
  • Reactions: 14
  • Comments: 17 (5 by maintainers)

Most upvoted comments

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

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.

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).

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

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.

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

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.