console.debug statements break the protocol

[sc68cal]

Summary

When running ansible-language-server with the --stdio flag (which appears to be the only supported way as of 1.0.4), console.debug statements are emitted on stdout. This is an issue because some systems like ycmd use language servers via stdout and interpret all data in stdout as protocol data, which causes ycmd to crash.

I have filed a bug on the ycmd side to make it more resilient to invalid protocol commands, but the opinion of the maintainers was that this language server also needs to behave better.

ycm-core/ycmd#1673

Extension version

» ansible-language-server --version
1.0.4

VS Code version

N/A

Ansible Version

ansible [core 2.14.1]
  config file = None
  configured module search path = ['/Users/sc68cal/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /opt/homebrew/Cellar/ansible/7.1.0/libexec/lib/python3.11/site-packages/ansible
  ansible collection location = /Users/sc68cal/.ansible/collections:/usr/share/ansible/collections
  executable location = /opt/homebrew/bin/ansible
  python version = 3.11.1 (main, Dec 23 2022, 09:25:23) [Clang 14.0.0 (clang-1400.0.29.202)] (/opt/homebrew/Cellar/ansible/7.1.0/libexec/bin/python3.11)
  jinja version = 3.1.2
  libyaml = True

OS / Environment

MacOS, ycmd

Relevant log output

https://github.com/ycm-core/ycmd/issues/1673

[ssbarnea]

@priyamsahoo @ganeshrn WFYT about this?

I did not dig into it but I based on standard POSIX practices we should:

• never print debugging messages on stdout, basically we should only send json
• we should always log on stderr, which may or may not have a standard format.

In theory we could log as json, but we cannot guarantee that everything send to stderr is json, as other libraries might log using non standard logging and break the output.

[sc68cal]

I would very much appreciate logging on stderr since ycmd already creates a file for stderr and redirects it to that file:

Printing YouCompleteMe debug information...

-- GenericLSP completer debug information:
--   ansibleCompleter running
--   ansibleCompleter process ID: 31414
--   ansibleCompleter executable: ['/Users/sc68cal/src/ansible-language-server/bin/ansible-language-serv
er', '--stdio']
--   ansibleCompleter logfiles:
--     /var/folders/kl/56c62hm51dd742lfbstbchgc0000gp/T/ansiblecompleter_stderr2j85exo_.log
--   ansibleCompleter Server State: Initialized
--   ansibleCompleter Project Directory: /Users/scolli010/src/comcast/DCN/lbaas-deploy
--   ansibleCompleter Settings: {}
-- Server running at: http://127.0.0.1:57513
-- Server process ID: 31401
-- Server logfiles:
--   /var/folders/kl/56c62hm51dd742lfbstbchgc0000gp/T/ycmd_57513_stdout_upc6i1n4.log
--   /var/folders/kl/56c62hm51dd742lfbstbchgc0000gp/T/ycmd_57513_stderr_e1303dqw.log
-- Semantic highlighting supported: True
-- Virtual text supported: True
-- Popup windows supported: True 

Logging to stderr also means that you don't have to worry about structure, since you can place anything you want in the file since most likely it will be read by human eyeballs, not machines

[JosBritton]

Non-spec stdout also breaks Sublime's LSP plugin sublimelsp/LSP#1612

[AmandaCameron]

Any chance we can get a point release containing ansible/ansible-language-server#604 now that it's been merged? Would be really helpful for people using different clients