"int object is not iterable" in deoplete source since 'next' branch

[languitar]

Since switching to the next branch, I am constantly receiving error messages from deoplete in the following form:

[deoplete] Traceback (most recent call last):
[deoplete]   File "/home/languitar/.local/share/nvim/bundle/deoplete.nvim/rplugin/python3/deoplete/deoplete.py", line 59, in completion_begin
[deoplete]     self.gather_results(context), context['input'])
[deoplete]   File "/home/languitar/.local/share/nvim/bundle/deoplete.nvim/rplugin/python3/deoplete/deoplete.py", line 185, in merge_results
[deoplete]     async_candidates)
[deoplete] TypeError: 'int' object is not iterable
[deoplete] Error while gathering completions.  Use :messages for error details.

@Shougo suspected that this is from the language client source, though it is not visible in the stracktrace. Unfortunately, I was not able to reproduce this in a minimal setup.

[Shougo]

@languitar Please disable LanguageClient-neovim and check if it is reproduced.

[languitar]

Doesn't appear without the language client source. Strangely, I cannot reproduce this with a minimal vimrc.

[Shougo]

https://github.com/autozimu/LanguageClient-neovim/blob/next/rplugin/python3/deoplete/sources/LanguageClientSource.py#L5

Hm.
The variable may have the invalid value. If the client is errored.

[languitar]

I will add some debugging...

[languitar]

There is a 0 in that variable when the error appears. I could patch the source to ignore such cases, but maybe finding the origin is a better approach.

[languitar]

Alright, and this seems to happen when the language server crashes:

2017-12-13 11:07:07,066 UTC - ERROR - pyls.server - Language server exiting due to uncaught exception
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/pyls/server.py", line 34, in handle
    data = self._read_message()
  File "/usr/lib/python3.6/site-packages/pyls/server.py", line 91, in _read_message
    raise EOFError()
EOFError

[languitar]

I have reported this at the language server project: palantir/python-language-server#203. However, after a short look at their implementation, it looks like the client is sending truncated messages to the server.

[autozimu]

Were you able to provide debug log? As I cannot reproduce the described issue locally.

[languitar]

LanguageClient.log
LanguageServer.log

There you go. After the update yesterday I don't get a single completion at all. The server immediately dies.

The language server developers say that the client is closing stdin.

[autozimu]

Could you follow issue template to fill out necessary information so that I can try reproduce it?

[languitar]

Things got even stranger today after updating to the latest release. Now, LanguageServer.log is always completely empty, warnings from the language server appear with an offset of one line, and the language client wastes more than 200% CPU constantly. I have not seen these issues with a minimal vimrc, but the original crashes of the server are still there, fortunately without error messages now. Yet, completions are missing most of the time then.

• neovim/vim version: 0.2.2
• Plugin version (git SHA): 6d0e953
• Minimal vimrc:

set nocompatible
set hidden

set runtimepath+=~/.local/share/nvim/bundle/deoplete.nvim
set runtimepath+=~/.local/share/nvim/bundle/LanguageClient-neovim

let g:deoplete#enable_at_startup = 1

let g:LanguageClient_serverCommands = {
    \ 'python': ['pyls'],
    \ }
let g:LanguageClient_autoStart = 1

• Language server name/link and version: https://github.com/palantir/python-language-server, 0.12.0
• Reproduction steps: randomly edit in the document. completions are often missing in deoplete and at some point in time you will find the EOFErrors in the server log.

LanguageServer.log

Client log got too big for uploading. Anything special I should look for in there?

[autozimu]

You could clear log files before reproduction, and then upload the log files.

[languitar]

I actually did clear it, but the few editing trials already resulted in about 50 MB of logs.

[autozimu]

Try use a different logging level.

:call LanguageClient_setLoggingLevel('INFO')