undefined variable s:job when calling LanguageClient#textDocument_references()

[TamaMcGlinn]

• Did you upgrade to latest plugin version? Yes; 0.1.160, downloaded directly from github repo at commit d6d6d08 on the 'next' branch.

• Did you upgrade to/compile latest binary? I downloaded the windows 64 bit binary according to the .ps1 script and verified that checkhealth finds it.

• (Neovim users only) Did you check output of :checkhealth LanguageClient?

health#LanguageClient#check

• OK: binary found: C:\Users\BC2SCF22\vimscripts\dein\repos\github.com\autozimu\LanguageClient-neovim_next/bin/languageclient.exe

• OK: languageclient 0.1.160

• OK: Floating window is supported and will be used for hover

• Did you check [troubleshooting] [troubleshooting]: https://github.com/autozimu/LanguageClient-neovim/blob/next/INSTALL.md#troubleshooting

All signs above show languageclient.exe is working, and the error message shows this is before even calling the language server - in fact, this even happens in filetypes for which I have no language server installed, where I would instead expect the error message 'no language server installed for ...'

Describe the bug

When I call the LanguageClient#textDocument_references() function, I get this error:

Error detected while processing function LanguageClient#textDocument_definition[5]..LanguageClient#findLocations[9]..LanguageClient#Call[22]..LanguageClient#Write:
E121: Undefined variable: s:job
E116: Invalid arguments for function jobsend
E15: Invalid expression: !jobsend(s:job, l:message)

Environment

• neovim/vim version (nvim --version or vim --version): NVIM v0.4.2 Build type: RelWithDebInfo LuaJIT 2.0.5 Compilation: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x64/cl.exe /DWIN32 /D_WINDOWS /W3 /MD /Zi /O2 /Ob1 /DNDEBUG -DMIN_LOG_LEVEL=3 /W3 -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -D_WIN32_WINNT=0x0600 -DINCLUDE_GENERATED_DECLARATIONS -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -IC:/projects/neovim/build/config -IC:/projects/neovim/src -IC:/projects/nvim-deps/usr/include -IC:/projects/neovim/build/src/nvim/auto -IC:/projects/neovim/build/include Compiled by appveyor@APPVYR-WIN

Features: -acl +iconv +tui See ":help feature-compile"

system vimrc file: "$VIM\sysinit.vim" fall-back for $VIM: "C:/Program Files/nvim/share/nvim"

Run :checkhealth for more info

• This plugin version (git rev-parse --short HEAD): d6d6d08

• This plugin's binary version (bin/languageclient --version): languageclient 0.1.160

• Minimal vimrc content: The minimal vimrc is enough.

• Language server link and version: Not relevant; this happens with no language servers configured at all.

To Reproduce

Steps to reproduce the behavior:

Run :call LanguageClient#textDocument_definition()

[martskins]

Could you confirm the output of :echo LanguageClient#binaryPath() and verify that the binary in that path is executable. I think this might be a duplicate of #619.

[TamaMcGlinn]

I'm on windows; everything is always executable because Microsfoot decided not to put up any pretense of security.

I don't see any connection to #619 - I am talking about an error in the vimscript, nothing to do with the binary.

However, after rebooting I am unable to reproduce the error. I have had this issue appear and disappear several times before so I am reluctant to just close it, although debugging will be very difficult.

[martskins]

The s:job variable is set after checking executable(binaryPath), that's why I was wondering that. Because if that call returns an unexpected value it won't set the value for s:job. Sadly I don't have a windows machine to check, but if you are happy to investigate I would suggest looking at the s:Launch function in autoload/LanguageClient.vim, maybe you can dig out some more info from there next time it happens.

[serhalp]

FWIW, this can also be the behavior if you haven't properly followed the installation instructions and run bash install.sh as prescribed. In that case the binary isn't present at all, which results in the above error.