Checkout to commit without specific file, shows errors for it and allows to reopen from problems tab

[FMorschel]

Does this issue occur when all extensions are disabled?: NA

• VS Code Version: 1.99.3
• OS Version: Windows_NT x64 10.0.26100

If you are at a branch that contains a file, open it (merge_combinators_test.dart in this example) and then git checkout to a commit without that file, it will start showing errors for the file and you are able to open it from the problems tab but the server doesn't send any errors for it specifically.

Steps to Reproduce (I've not yet tried, but I suspect other languages will also suffer from this):

1. Clone https://github.com/FMorschel/sdk/tree/stale-analysis
2. Open pkg/analysis_server/test/src/services/correction/fix/merge_combinators_test.dart and
3. Run git checkout 54c8719dfac436f395b4c4078085d5ed8f0dfc51 (https://github.com/dart-lang/sdk/commit/54c8719dfac436f395b4c4078085d5ed8f0dfc51)

https://github.com/user-attachments/assets/bb4ddaa8-54c6-4fef-a7bd-1ff897e616ae

Note: the original report started here. Some other people could not reproduce my video above. Any ideas on how to debug this problem would be great, thanks!

CC @DanTup

[DanTup]

I've unfortunately not been able to reproduce this, and the LSP logs look normal (we send some diagnostics for that file during the branch switch, then we send an empty set when the file is removed).

My feeling is that there might be some race between the LSP client setting the diagnostics for this file and VS Code noticing it deleted from disk, but I still wasn't able to reproduce it with various timings on my machine.

My main question here is where this file content is coming from. It seems like VS Code has kept a copy of the file somewhere and is restoring it when you click on the diagnostic in the Problems view - this doesn't seem like expected behaviour to me - if the file is closed and has been deleted from disk, I don't think VS Code should ever be pulling a stale copy of it from anywhere (whether this is also where the stale diagnostics are coming from, I'm not sure).

[lszomoru]

@bpasero, @jrieken, any suggestions on this one would be appreciated. Thank you!

[bpasero]

My main question here is where this file content is coming from. It seems like VS Code has kept a copy of the file somewhere and is restoring it when you click on the diagnostic in the Problems view - this doesn't seem like expected behaviour to me - if the file is closed and has been deleted from disk, I don't think VS Code should ever be pulling a stale copy of it from anywhere (whether this is also where the stale diagnostics are coming from, I'm not sure).

If a text model (document) is associated with the URI and still around in memory, we will show it from there, even if the file is missing from disk. We still try to fetch the latest contents from disk but fail silently.

In other words: something has created the text model, but it was not disposed (yet).

@jrieken I remember that for documents created from extensions we keep them around for some time before auto disposing them? Or is there a rule that disposes them at once when a file is deleted?

[FMorschel]

Another note I forgot to mention, I do have closeOnFileDelete set to true

"workbench.editor.closeOnFileDelete": true

[jrieken]

Or is there a rule that disposes them at once when a file is deleted?

Yeah, on move or delete we clean-up references

[DanTup]

How can we help track down why we still see Problems from a file that's deleted and the extension has removed the diagnostics for?

From the logs, it appears that this is what happens:

• branch change in git
• diagnostics are produced for the file because it's analyzed during the branch change (when the code is incomplete)
• the file is deleted
• diagnostics are cleared (by the LSP server)

At the end of this, there should be no diagnostics and the file is deleted, but VS Code is still showing diagnostics, and clicking them opens a version of the document we don't think should exist. I wondered if there might be a race with VS Code handling the delete, and the LSP server providing the empty set of diagnostics, however I can't repro that by trying to influence the order of those (and I don't know enough about VS Code to know if that's even a plausible issue).

I suspect it will be difficult to get your a repro (since I can't repro myself), but if you have ideas about what might be going wrong or how we can debug, perhaps @FMorschel can help debug it with breakpoints in the dev tools or by running Code from source?

[FMorschel]

I've now been able to reproduce this behaviour when I had a test file I was editing (it had a bunch of errors from placeholders), and I decided to move some stuff and delete that file.

On deletion, the file got closed in the editor, but the problems tab errors persisted. Maybe you can reproduce it this way? I'm on the latest stable VS Code. As a reference, the file had 36 errors (maybe the amount is relevant in some way).

[DanTup]

Maybe you can reproduce it this way?

I couldn't, although we probably didn't test with the same file. Can you repro reliably? If you can on a public file, I can try exactly the same. My feeling is that this may be a race though, and our machines might perform differently.

[FMorschel]

Can you repro reliably?

I've not managed to create a small public project that can repro that, yet.

If you can on a public file, I can try exactly the same.

I'll keep trying to repro this in my free time. If I find any news, I'll post here.