How to log deno lsp communications?

[jaydenseric]

I'm having a very rough time trying to log the stdin and stdout/stderr communications of the deno lsp command, to debug problems with my Nova editor Deno extension (the command is invoked here).

How do you do it?

I've tried the --log-level debug option, but that doesn't log the stdio traffic, just Deno internal activity. I've tried crazy bash tee related hacks and it only manages to log a bit of traffic, then nothing over time. Googling how to log stdin, stdout, and stderr of a command without disrupting it in bash has been a hugely unproductive so far.

[kitsonk]

The language server protocol runs over stdout, so anything going to stdin or stdout is processed by the language server.

By default, there is some debug information to stderr. There are also two sets of diagnostic information available. There is the deno/virtualTextDocument of deno:/status.md which will provide a dump of diagnostic information in markdown format, and then there is the deno.internalDebug setting (or just internalDebug in the initialisation options). Setting this to true will log out to std err the internal performance markers within the language server for requests it receives as well as other internal functions, including the serialised version of the payload.

[jaydenseric]

I did try the deno.internalDebug setting, and while it printed to stderr internal performance markers, etc. I could't see any serialized versions of the request and response payloads, or at least the ones for the methods I was interested in were missing.

In the end, I managed to get this going just enough to figure out a bit more what was going on:

bash -c tee -a ~/Sites/nova-deno/lsp_input.txt | deno lsp | tee -a ~/Sites/nova-deno/lsp_output.txt

[kitsonk]

It is only the payloads received by the language server.

When developing the language server I tend to use the test harness (https://github.com/denoland/deno/blob/main/test_util/src/lsp.rs) to send messages and then println!() the responses before I finalise the test or if I want to see what is going on. The internal debug is useful to identify and re-create messages going into the server using the harness.