Deno lsp showing false errors and stops linting new code, requires reloading window to resolve

[KyleJune]

In the video linked below, both primaryGroupServiceTests and secondaryGroupServiceTests are a valid first argument for the test function. I recorded this last week and no longer have the code. I tried finding a minimum reproduction path but it seems to happen randomly. To capture it happening I just had to record myself coding. It was most common for me when using backspace or deleting lines. Sometimes I would have it happen to me after running deno fmt in the terminal. If I use the command to restart language server, it doesn't resolve the issue. I end up having to frequently use the reload window command to resolve the issue.

https://www.youtube.com/watch?v=9kmzApeIxp8

Here is a link to the start of a discord conversation where others had noted that they experienced the same issue as me. https://discord.com/channels/684898665143206084/684898665151594506/835903650152972368

[wperron]

Moving this as it is an LSP issue rather than a linting issue

[danopia]

I've been experiencing this pretty often (depending on what I'm working on, ranging from 1/hr up to every minute or two) and it seems to be some sort of 'stuck request' issue.

Before reloading the window I usually try running pkill deno in a terminal. This usually results in a huge pile of "Connection disposed" or "Connection to server is erroring" messages appearing. Often the lsp comes back up and then everything updates after the pkill, but other times it stays broken and I reload the editor.

I only recently found Restart Language Server and both times I tried it, the incorrect error spans went away, but nothing replaced them and I still had to reload the window.

Assuming this is the same issue, it's pretty hard to figure out what's not working; I'm not sure what debugging I can do once the bad state is recreated.

Here's an instance where I had already backspaced ApiResponse to Response and the LSP didn't notice, until I tried pkill deno then everything works again:

Untitled_.Apr.25.2021.7_32.PM.mp4

Here's a screenshot from 20 days ago showing the other message spam that often happens after pkill deno:

[danopia]

Here's an example (again, already stuck, as I haven't been generally screen recording) where the Restart LSP option doesn't restore the LSP health.

Notice how the deno lsp processes running afterwards are not recent. I suspect that the restart command is also hanging waiting for an LSP command to complete. It seems there's a "shutdown" command that is issued, deep down in VSCode: https://github.com/microsoft/vscode-languageserver-node/blob/faa68d90a976f158a8403a0f5cce54117ce61dbb/client/src/common/client.ts#L202 which would explain why the Restart LSP command doesn't work in this case.

Untitled_.Apr.26.2021.9_13.AM.mp4

I then did pkill deno which gave the Connection to server is erroring spam, but (likely because of the restart LSP attempt) didn't restore LSP health either in this case.

[kitsonk]

@danopia I created #10438 to add additional logging when the client sends deno.interernalDebug to true and spent the day trying to recreate it (I have had it happen a couple times) and I couldn't get it recreate. Hopefully once the PRs get reviewed we can merge it and try to catch it a bit more in the wild.

My theory is that there are requests into tsc that are hanging for an unknown reason, that would explain all the subsequent behaviours, the problem is I just don't know what request it is. The additional debug logging should help try to catch it, or at least be able to see if there is an easy way to reproduce.

[danopia]

I'll definitely give that flag a try when it's available. I've had this happen a dozen times in one session, and any way of gathering info on what's not working should be useful 😃

I suspect that a slower machine leads to more occurences; just a hunch right now, but I seem to get more hangs when a deno --watch process is doing repeated checks in the background, which would create some competition for processor time.

[KyleJune]

I suspect that a slower machine leads to more occurrences; just a hunch right now, but I seem to get more hangs when a deno --watch process is doing repeated checks in the background, which would create some competition for processor time.

My machine is fast and has 24GB of ram and I had it happening frequently. I don't use deno --watch but I do run tests frequently as I work on code. I'm using VS Code with WSL: Ubuntu-20.04.

[kitsonk]

Ok, I haven't been able to use debug builds of my Deno on my machine for an extended period of time due to another bug, and now that that is fixed, I have been able to run debug builds on my machine. Debug builds run significantly slower than release builds which means they tend to catch these things a lot easier and lo and behold, I was working on a project where I was getting these hangs ever couple of minutes, so I switched over to the diagnostic branch and caught it, which is giving me more information to narrow down what is going on.

So I have at least a set of breadcrumbs to try to chase down now. It looks like some sort of deadlock issue in tsc, which is sort of what I expected, thought I don't know exactly what it is yet.