Inifinite recursion in logger

[kokobd]

This was originally found in https://github.com/haskell/haskell-language-server/pull/3072

In lsp, there is a debug log, printing response body: https://github.com/haskell/lsp/blob/8b63438313828a31ba1065ea865e504d532d093e/lsp/src/Language/LSP/Server/Control.hs#L224-L234 And in HLS, our logger sends a copy of log to LSP client: https://github.com/haskell/haskell-language-server/blob/347a7187f20242540926b9927c59a45b18798c67/exe/Main.hs#L72-L82

Then it goes into infinite recursion. A lot of logs like below are produced, and finally OOM on a machine with 64GB RAM.

[michaelpj]

The problems are:

1. This log is useful, it's handy to be able to see the actual response body.
2. We would like to see this log in the HLS server log file.
3. It would be somewhat nice to see this in the client log file.
4. We sometimes want to see debug logs, and we don't have a severity below debug.

I think my best idea is to specifically filter out the window/showMessage and window/logMessage messages and not log them. That makes this log marginally less useful, but also they're super noisy and probably not that interesting.

[soulomoon]

What is the state of it. 🤔 It is safe to enable the log now?

[michaelpj]

No, I never really figured out a good solution to this. We need to do one of two things to break the recursion:

1. Not log the problematic window/logMessage messages
2. Not send window/logMessage messages for the problematic logs

[michaelpj]

I think I'm leaning towards the latter now, since that means that that lsp can continue to log things in full, and it's just the bit that sends logs to the client that needs to behave differently.

[soulomoon]

does it mean we need to do it in hls?

[michaelpj]

We also export a client logger from lsp. I'm not sure if HLS has its own, I'd need to look.