Repository navigation
Persistent incorrect semantic diagnostic after large rebase or checkout: File is not listed within the file list of project #47274
Description
Bug Report
When using tsserver in VSCode, I sometimes see persistent false error reports from diagnostics after a large rebase or checkout of the form, "File '{}' is not listed within the file list of project '{}'. Projects must list all files or use an 'include' pattern." The file mentioned in the error is a file that was newly created as part of the checkout or rebase. After waiting several minutes and noticing that the logs are idle, the only solution is to restart tsserver.
I have a repro case I would be willing to demonstrate live. In the repro, I have a file open (call it OpenFile.tsx) which imports a new file (call it NewFile.tsx). Here is a timeline of events in the logs related to a file that repros this issue:
- A DirectoryWatch event of type Wild card directory is triggered for NewFile
- A DirectoryWatch event of type Failed Lookup Locations is triggered for NewFile
- Lots of other watch processing is happening...
- A projectUpdatedInBackground event fires for the project that OpenFile and NewFile belong to
- A request comes into the language service for OpenFile's diagnostics
- An upgradeGraphWorker starts for the project that OpenFile and NewFile belong to
- A FileWatch is added for NewFile (Closed Script info type)
- The upgradeGraphWorker completes, and NewFile is listed in the long list of files and "Imported from" statements
- semanticDiag reports an error for OpenFile
In separate repros, I've noticed that...
(1) and (2) can swap places
(4) does not always happen. Maybe something else triggers the request?
🔎 Search Terms
IDE, VSCode, tsserver
🕗 Version & Regression Information
I don't have any information about when this started. It's been a problem that we have noticed for a long time. Our project is on 4.5.4
⏯ Playground Link
I can repro this but not on playground
💻 Code
I can repro this but not on playground
🙁 Actual behavior
A persistent incorrect semantic diagnostic saying that a file is missing after a large rebase or checkout
🙂 Expected behavior
After a reasonable amount of time, no semantic errors
Activity
MarcCelani-at commentedon Dec 30, 2021
I have a suspicion that part of the problem here is in updateProjectIfDirty:
It appears that the expected result of this function is true if the project changed. But Project.updateGraph returns true if the project did not change.
That may implicate this code:
TypeScript/src/server/editorServices.ts
Line 1195 in 3254358
But patching updateProjectIfDirty does not appear to solve the problem. Maybe a separate bug?
IMO updateGraph returning true when the project does not change is kind of confusing...
MarcCelani-at commentedon Jan 16, 2022
I wouldn't say fix is available. I think my PR fixes a bug, but maybe I'm wrong, or there must be other bugs, because this still repros for me.
andrewbranch commentedon Jan 18, 2022
Do you have a repo I can access that demonstrates this problem? Is it 100% consistent, or does the error turn up randomly / in different places?
MarcCelani-at commentedon Jan 18, 2022
No, we cannot share our repo with you, but I am happy to debug this with you over VC. I think you are on an email thread with me about this.
This repros extremely consistently, especially after the fix in #47466. As in, when I switch branches, it is the exact same files that are always missing.
andrewbranch commentedon Jan 21, 2022
So this is not fixed by #47482?
MarcCelani-at commentedon Jan 21, 2022
Correct, the two issues are separate.
#47482 fixes #47466, which happens if typescript sets a watch on a pre-existing file and that file changes more than one time.
#47464 relates to when a new file is created. It repros with a single git checkout if changing branches causes git to produce a new file. In my repro case, it happens consistently with the same file, but I do not have a very simple repro case to demonstrate what is going on. Based on logs I've seen, I don't think #47464 is a watch bug, I think it is something different, more complex..
andrewbranch commentedon Jan 21, 2022
If you open the file that’s being complained about in VS Code, what happens then? (I will be able to pair debug with you on this during the 4.7 timeframe.)
MarcCelani-at commentedon Jan 21, 2022
In #47466, opening the file fixes the erroneous diagnostic.
In this issue, opening the "missing" file does not fix the erroneous diagnostic.
MarcCelani-at commentedon Mar 27, 2022
My PR was rejected and I'm out of ideas here. I'd love to connect with folks from typescript to debug and fix this one.
sheetalkamat commentedon Mar 28, 2022
Are you on Mac or Linux.. Can you share tsserver log where the issue repros (if needed privately) for me to diagnose.
andrewbranch commentedon May 25, 2022
Sheetal Nandi (@sheetalkamat) someone reported what sounds like the same behavior in #49078 and has an open source repo for it
andrewbranch commentedon May 25, 2022
Marc Celani (@MarcCelani-at) can you check if #49246 solves this?
MarcCelani-at commentedon May 26, 2022
I will try!
DanielRosenwasser commentedon Jun 2, 2022
It sounds like this is the same as #49078, which #49246 should fix. Either way, there is another issue you all are hitting (#47466) which hopefully #48997 will address. I'm going to mark this as closed for 4.7.3.
MarcCelani-at commentedon Jun 2, 2022
Ok. For what it's worth I haven't had a chance to confirm this issue is fixed by that change but I can reopen later if it doesn't get fixed by the change in 4.7.3.
divmgl commentedon Jan 27, 2024
Just a heads up that this is still happening as of the latest version of TypeScript.