Cleanup issues with old .vdocs

[lgaborini]

Bug description

I'm using Positron with Quarto extension 1.124.0, this issue might be related to #708 (confirmed fixed).

The former syntax errors keep piling up under the Problems panel, even if the files in the Temp directory (or the directory itself) are no longer there:

(I'm editing a fairly large Quarto project with many files and Positron is getting sluggish. Not sure if this is the culprit!)

Steps to reproduce

No response

Actual behavior

No response

Expected behavior

Empty Problems window if the project contains no syntax error

Your environment

Positron Version: 2025.09.0 (user setup) build 139
Code - OSS Version: 1.103.0
Commit: 30e3d0a74e09a0f6640929822cb57a326671360e
Date: 2025-08-29T18:50:28.998Z
Electron: 37.2.3
Chromium: 138.0.7204.100
Node.js: 22.17.0
V8: 13.8.500258-electron.0
OS: Windows_NT x64 10.0.19045

Quarto extension: 1.124.0

[juliasilge]

I have run into this as well sometimes (even after fixing #708), and also observe this:

even if the files in the Temp directory (or the directory itself) are no longer there

I can't exactly remember what steps resolve it, but I think it was something like restarting the R/Python interpreter or maybe doing Developer: Restart Extension Host (or maybe closing and reopening Positron). The next time you see this, can you try out some of these, to let us know what fixes all the ghost .vdocs? This will help us find out what may be going wrong.

[lgaborini]

How embarrassing, restarting Positron did not fix it before submitting this Issue, but restarting the Extension Host clears the panel.

The R session is alive, but the language server seems to no longer work.
I lose all R autocomplete, CTRL+Enter just sends one line to the console (a bit like the linked issue) in .qmd or .R files, it does not wait for end of pipes or closing brackets.
If there are no syntax errors, Air still works.

With Developer: Reload Window, Positron becomes fully functional again, but the phantom .vdocs are back.
It just takes saving one file with one syntax error to get an entry in the panel, even if the file is fixed and saved again.
I confirm that the offending .vdoc is deleted, but I can still see its contents by clicking on the Problems view (this should point to some sort of Positron/VS Code cache).

Simple reprex:

---
title: "Quarto test"
---

```{r}
#| label: setup
library(tidyverse
```

The problem reads: Unmatched opening delimiter. Missing a closing ')'.

If I do the same with an R file, the entry correctly disappears once I fix and save the file.

Plus I'm further aggravating the issue since I'm using {targets} to load the variables.
At some point the LSP picks up the bound names, but it takes a lot of time (I have noticed that they disappear after a while, working on other files and so on — but I haven't further investigated on the issue).
But this is probably a separate topic.

[juliasilge]

It just takes saving one file with one syntax error to get an entry in the panel, even if the file is fixed and saved again.

Ahhhhh perfect, thank you for sharing this! I can reproduce the problem as you outline, which is excellent news. I think this is important for us to fix fairly expeditiously, because these .vdoc files can get very numerous, and they are super confusing given that users aren't really supposed to even know they are there.

Our approach of literally writing little temp files to get language features in .qmd has some real downsides, such as bugs like this.

[juliasilge]

Maybe reporting problems/diagnostics for the .vdoc files doesn't make sense at all; it's very confusing to users what these files even are.

[lgaborini]

I agree! Especially given that these files no longer exist in the filesystem, but one can still open them.
It's already a miracle that I don't get more errors such as locked files due to Onedrive/Dropbox or shared drives...

I just hope you can find a way to make diagnostics work otherwise: maybe use one file for everything, just to fill up the panel?

[juliasilge]

Reported again in posit-dev/positron#9490, specifically mentioning performance problems once you get several thousand of these

[juliasilge]

We've got a fix for this merged in now, with #832! This will be available to users the next time we release the Quarto extension.

[lgaborini]

Thanks, everything is super fast now!