Stale diagnostics

[Gelio]

Hey!

I have been using this project instead of nvim-lspconfig's tsserver for quite some time.

I have noticed that from time to time, I have stale diagnostics that I cannot seem to get rid of. Using LspRestart on LspStop on the typescript-tools LSP client does not help. Neither does bd! on the buffer. The only thing that helps is restarting Neovim.

This is annoying, since I lose my loaded buffers and need to open them again.

Example of stale diagnostics:

Let me know how I can help debug this problem if I encounter it again. I haven't looked at the source code of this project yet.

[pmizio]

If you will be able to provide more info and steps to reproduce I will do my best to fix it. I use this in my commercial job daily and for me it isn't doing this or maybe I just didn't notice this error. But if you find way to reproduce then other info can be useful:

1. nvim version
2. typescript version
3. some code/example project to reproduce

[roguesherlock]

I just wanted to chime in and say that I also have this problem in my monorepo setup. I'll try to setup a example repo and get back to you.

[macstr1k3r]

+1

nvim: 0.9.4 Ts: 5.3.3

[pmizio]

@Gelio @roguesherlock @macstr1k3r So I added feature which may help debug this:

:lua require("typescript-tools.api").save_snapshot_to("snapfile.js")

this should save current tsserver in memory representation of affected file you can compare it to your file and check if it is same as yours. If yes it's probably some bug in tsserver or neovim itself because on our side we just translate response from tsserver and push them to neovim, we won't store them or anything. If files are different probably it is our problem because this is probably sync problem.

Let me know about your findings. Connected pr: #212

[Gelio]

I just hit this problem. The snapfile.js is identical to the original file that I see stale diagnostics.

You can see stale diagnostics in the original source file on the left. The file on the right is the snapfile.js and it has the same source code as the original file.

You can ignore the errors in the file on the right. tsserver is complaining about using TypeScript syntax in a js file. The snapfile.js should have been named snapfile.ts.

Your comment suggests that this is a problem in Neovim/tsserver. I never had those problems when using tsserver directly via nvim-lspconfig or when using https://github.com/jose-elias-alvarez/typescript.nvim earlier. Let me know I can help you debug further.

[pmizio]

@Gelio So, I started to dig in this but without any reproduction is hard to debug it. But I started to look for some nvim diagnostic api and I bumped on vim.diagnostic.reset(). As far as I understand code of this function it should fully clear diagnostics, namespaces containing text decorations and diagnostic cache. Next time when you bump into this issue can you invoke :lua vim.diagnostic.reset(), it kill all ordinary diagnostics for me IDK it kill also stale ones. But it's worth to try so I created draft PR which use this function to reset diagnostics instead standard lsp notification. Try to switch on branch from this PR and let me know if problem still appear.

[pmizio]

Probably second solution will be to use builtin nvim pull diagnostic but its implementation miss relatedDocuments functionality which is necessary for tsserver. In free time I'll try to extend this in core nvim.

[Gelio]

I understand and agree it's hard to analyze and also hard to reproduce. I don't see a set of steps that leads to this bug.

I'll try running vim.diagnostic.reset() when I encounter this problem again and post back with the results.

[siblanco]

@Gelio So, I started to dig in this but without any reproduction is hard to debug it. But I started to look for some nvim diagnostic api and I bumped on vim.diagnostic.reset(). As far as I understand code of this function it should fully clear diagnostics, namespaces containing text decorations and diagnostic cache. Next time when you bump into this issue can you invoke :lua vim.diagnostic.reset(), it kill all ordinary diagnostics for me IDK it kill also stale ones. But it's worth to try so I created draft PR which use this function to reset diagnostics instead standard lsp notification. Try to switch on branch from this PR and let me know if problem still appear.

can confirm - :lua vim.diagnostics.reset() actually clears diagnostics and I can continue without restarting vim :)

edit: let me add that, while it works most of the time, sometimes it kind of destroys the lsp and I need to LspRestart to get going again. Not sure if this would be the optimal solution.

I'll try out your PR and will provide feedback about how it goes. edit2: trying your PR for 30min ish, I experienced 3 freezes - reverting!

FYI - this happens quite often to me when working on a larger monorepo project.

[macstr1k3r]

@pmizio still getting this from time to time but never in a moment when I have time to investigate further so :LspRestart + :e! is my goto solution

[asiborro]

Hello folks, I'm experiencing this exact same issue on a quite large monorepo. I can get at most 10 minutes before the diagnostics go stale. On non monorepo setups works flawlessly. :LspRestart + :e! does not work for me unfortunately.

[jenrzzz]

I suspect something is getting wonky when simultaneously editing files from different packages within the monorepo.

[myypo]

I had a similar issue when working with gopls. What helped is disabling incremental sync, which probably has some negative impact on perfomance but it solved my issue with gopls back then.

flags = {
    allow_incremental_sync = false,
}

[dan-cooke]

Also experiencing this issue in monorepos, have not had time to debug in non-monorepos yet.

@pmizio thanks for that PR, I will switch to it and see if it works

[dan-cooke]

Just an update @pmizio I have been using your draft PR for the last week and its definetly fixed any issues with stale diagnostics. Have not had to restart the LSP since

Amazing!