Persistent incorrect semantic diagnostic after large rebase or checkout: File is not listed within the file list of project

[MarcCelani-at]

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:

1. A DirectoryWatch event of type Wild card directory is triggered for NewFile
2. A DirectoryWatch event of type Failed Lookup Locations is triggered for NewFile
3. Lots of other watch processing is happening...
4. A projectUpdatedInBackground event fires for the project that OpenFile and NewFile belong to
5. A request comes into the language service for OpenFile's diagnostics
6. An upgradeGraphWorker starts for the project that OpenFile and NewFile belong to
7. A FileWatch is added for NewFile (Closed Script info type)
8. The upgradeGraphWorker completes, and NewFile is listed in the long list of files and "Imported from" statements
9. 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

[MarcCelani-at]

I have a suspicion that part of the problem here is in updateProjectIfDirty:

        /*@internal*/
        function updateProjectIfDirty(project) {
            project.invalidateResolutionsOfFailedLookupLocations();
            return project.dirty && project.updateGraph();
        }

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

hasChanges = updateProjectIfDirty(project) || hasChanges;

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]

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]

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]

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]

So this is not fixed by #47482?

[MarcCelani-at]

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]

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]

In #47466, opening the file fixes the erroneous diagnostic.

In this issue, opening the "missing" file does not fix the erroneous diagnostic.

[MarcCelani-at]

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]

Are you on Mac or Linux.. Can you share tsserver log where the issue repros (if needed privately) for me to diagnose.

[andrewbranch]

@sheetalkamat someone reported what sounds like the same behavior in #49078 and has an open source repo for it

[andrewbranch]

@MarcCelani-at can you check if #49246 solves this?

[MarcCelani-at]

I will try!

[DanielRosenwasser]

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]

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]

Just a heads up that this is still happening as of the latest version of TypeScript.