File changes not reported after update to 1.91.1

[alasdairwilson]

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

• VS Code Version:
  Version: 1.91.1 (user setup)
  Commit: f1e16e1
  Date: 2024-07-09T22:06:49.809Z
  Electron: 29.4.0
  ElectronBuildId: 9728852
  Chromium: 122.0.6261.156
  Node.js: 20.9.0
  V8: 12.2.281.27-electron.0
  OS: Windows_NT x64 10.0.19045

Extensions:
Issues are still present with only the WSL remote extension enabled.

I don't know the cause of this and can't provide any reproduction steps but since updating today to the latest version of vscode the source control git integration has become buggy and unresponsive in several ways.

• Changes do not appear in the sidebar unless a manual refresh is performed (even after trying "git.autorefresh": true,)
• Related: Staging changes via terminal are not reflected in the sidebar without a refresh
• Committing is very slow, commits from the terminal are not reflected quickly in the sidebar
• Upon rebasing a branch and force pushing, the "sync changes" button did not reflect the remote and local branches were equivalent (still said 3 ahead 7 behind) clicking sync changes caused it to sit there with the progress indicator until it was closed and reopened.
• Swapping branches via the ui was very slow, checking out branch is not reflected in sidebar without manual refresh

I don't know if this is a just me issue as I can't see any other issues about this in github.

[torickjdavis]

This appears to be related to issue #221378.

[claycoleman]

major +1 from me, this ends up being a major blocker as the source control status and edited files used to update on window refocus, file save, and other scenarios, but now requires a manual click of the refresh button to get latest data. like OP said, it seems to happen sporadically and seems to work for a period of time before it gets into a bad state.

[fredrik-j-lindberg]

Same issue here on the same version, have to manually refresh the source control for every change to be reflected properly

Renaming of files also did not prompt me to fix imports as it normally does, not sure if that is related

[lszomoru]

If you are able to reproduce this issue consistently, could you please follow this wiki and share the logs for the file watcher?
This should help us track down whether the issue is related to the file watcher of the git extension. Thank you!

[fredrik-j-lindberg]

I seem to have no output from file watcher (tried with "File Watcher" as well), let me know if I am doing something wrong @lszomoru

FileWatcherDebug.mov

[lszomoru]

@bpasero, do you mind taking a look at this. Thank you!

[bpasero]

This issue could originate from a problem with file watching. Let me explain how file watching works in VSCode first and then provide some details how to get more logging data from how file watching behaves in your case.

Synopsis
VSCode has different strategies for file watching depending on your workspace and setup:

• no folder opened: files in opened editors are watched via node.js fs.watch
• folder opened: folder is watched recursively for all changes via parcel, opened editors with files not within the folder are watched via node.js fs.watch

If you are connected to a remote (SSH, WSL, Docker), the file watcher will run within the target file system. As such, even though you maybe on Windows where VSCode runs, if the remote is Linux, the file watcher will run in the Linux environment.

Platforms
Depending on the platform you are on, file watching is differently implemented:

• macOS: using fsevents services
• Windows: using ReadDirectoryChangesW method
• Linux: using inotify

Specifically on Linux, watching a large folder recursively can result in VSCode consuming too many file handles. If that is the case, you will see a warning notification with instructions how to solve that.

Limitations
File watching comes with a set of limitations:

• symbolic links are not followed automatically but you can explicitly add symbolic links to be watched via the files.watcherInclude setting
• mapped network drives or third party file system drivers are not guaranteed to produce file events
• in general, the operating system may decide to drop file events at any time, there is no 100% guarantee

Settings
Please review your settings to see if maybe a folder is excluded by accident. Specifically, the files.watcherExclude setting is relevant.

Logging (local)
!!! This is ONLY when you open a local workspace, for remote see below !!!
We provide logging for file events when you enable verbose logging. Steps are:

• open VSCode on the local workspace that shows the issue
• select View | Command Palette...
• select Developer - Set Log Level...
• pick Trace
• select View | Output
• select File Watcher from the dropdown on the right
• attach the output when doing the operation that exhibits the issue

Logging (remote)
!!! This is ONLY when you open a remote workspace (WSL, Docker, SSH), for local see above !!!
We provide logging for file events when you enable verbose logging. Steps are:

• open VSCode on the remote workspace that shows the issue
• select View | Command Palette...
• select Developer - Set Log Level...
• pick Trace
• select View | Output
• select Log (Remote Server) from the dropdown
• attach the output when doing the operation that exhibits the issue

[fredrik-j-lindberg]

But the logs provided no info whatsoever @bpasero, see my video above

I don't have files.watcherExclude set in my settings.json

[fredrik-j-lindberg]

I just realized that the guide that you send @bpasero sightly differs from the wiki guide, by the looks of it yours is telling me to look in the output tab for it. But I don't have any option to select it there:

[fansek]

Hi all,

I had the same issue.

A moment ago I decided to install an older version of VS Code (version 1.90) from this site
and file watching began to work.

Then I retried to update VSCode just to see if there are any differences in File Watcher output between 1.90 and 1.91, but after VSCode restart there was no File Watcher option in the dropdown menu of output view and file watching stopped to work again.

Then I found out that I had some extensions enabled. So I disabled them and file watching started working again. I discovered, that it was ESLint in combination with the new VS Code that was probably causing the trouble in my case. However, after a couple of times of restarting VSCode with extensions either disabled or enabled, it currently works with enabled extensions and I can't reproduce the issue anymore.

Do you guys also tried to run VS Code with disabled extensions?

My current configuration:

Version: 1.91.1
Commit: f1e16e1
Date: 2024-07-09T22:07:46.768Z
Electron: 29.4.0
ElectronBuildId: 9728852
Chromium: 122.0.6261.156
Node.js: 20.9.0
V8: 12.2.281.27-electron.0
OS: Darwin arm64 23.5.0

[ZenabKhan]

Hey I have the same issue. I followed @bpasero steps. Sharing my filewatcher screenshot

[bpasero]

Does it help at all to set typescript.tsserver.experimental.useVsCodeWatcher to false in settings and restart?

[fredrik-j-lindberg]

Does it help at all to set typescript.tsserver.experimental.useVsCodeWatcher to false in settings and restart?

That seems like it did the trick for me! 🙏 Both the source control and the file renaming now works for me

FYI I am heading off to vacation for two weeks so I will be unable to help further debugging this, but thanks for looking into it and providing a fix!

[ZenabKhan]

@bpasero

typescript.tsserver.experimental.useVsCodeWatcher to false

works me. Thanks 🙏

[bpasero]

Can people that are impacted share steps how to reproduce, specifically what workspace they open and which extensions are involved?

[liamdawson]

I think it might be related to using pnpm in my case — maybe heavy usage of symlinks in the node_modules folder causes issues? Wiping node_modules and reinstalling them using bun instead seemed to resolve the issue when I reloaded the window.

[bpasero]

@liamdawson thats a good finding, would you be able to share a repro with me that I can follow along to test this step by step?

Are others also using a setup like that?

[fansek]

Hi @bpasero, I also use pnpm. However, files.watcherExclude config param with **/node_modules/*/** pattern should exclude any node_modules directory from watching, shouldn't it?

[bpasero]

@fansek only for the workspace watcher VS Code installs, however with typescript.tsserver.experimental.useVsCodeWatcher: true (which is the default), TypeScript extension will install watchers specifically in the node_modules folder and the setting has no effect in that case because extensions fully drive the file watching.

With typescript.tsserver.experimental.useVsCodeWatcher set to false, TypeScript leverages node.js built in watching, which probably does not fall over circular symlinks.

Again, a repro would be great on a repo I can try with!

[slavos1]

An interesting discussion.
To add my 2¢, am on Ubuntu 24, have pnpm, allowed Trace log level, seeing FileWatcher output.
I have installed a random package (pnpm i lodash) and I do not see any increased load and I do not have fileWatcher process (because inotify is used on Linux?) and I do not observe any CPU increase.

[bpasero]

There should always be a fileWatcher process as child from the main process in VS Code, even on Linux. Yes, we use inotify but we always isolate the file watcher process from the rest by using a child process.

[slavos1]

Ok, thanks, @bpasero for explaining. I checked manually for such a process and couldn't find any. But I was experimenting only for a very short time. I may want to double check it again since there was some FileWatcher output, so something was running.

[slavos1]

Tested again, not seen any fileWatcher process.😞

I did:

• set Log error level to Trace
• opened "File Watcher" output log
• created a new file test.js and started changing it
• seen events in "File Watcher" corresponding to my changes, as expected
• have not caught any fileWatcher process, even intermittently (was running very crude monitoring with while true; do ps -ef | rg '[w]atch' -i|rg -v '/code/[c]ode|\[watchdogd\]'|rg -vw rg; sleep .01; done)

Sample output:

2024-08-02 21:59:45.446 [trace] [File Watcher (parcel)] [CHANGED] /home/user/test.js
2024-08-02 21:59:45.496 [trace] [File Watcher (parcel)] [CHANGED] /home/user/test.js
2024-08-02 21:59:45.522 [trace] [File Watcher (parcel)]  >> normalized [CHANGED] /home/user/test.js

[bpasero]

@slavos1 you can use VS Codes built in process explorer (from the help menu) to spot it:

Note: if you are connected to a remote machine, the file watcher would run inside the remote.

[cpojer]

@bpasero I ran into it a few more times, but muscle memory kicked in too quickly and I restarted the TS server each time 😅 I just created another file in the project mentioned above, in athena/lib. When trying to auto-import symbols via cmd+., I saw that the file watcher was indeed stuck at 100:

[ericallam]

This has been happening to me, and I saw this in my File Watcher log. That @trigger.dev/core-apps is an cross-monorepo package that was being set as a dependency of another monorepo package with workspace:*. I was doing some refactoring and have removed the core-apps package. We also use pnpm.

[bpasero]

That log message is actually fine, we have some logic to handle paths either missing or being added or deleted while watching. It should not result in a 100% CPU spike.

[ericallam]

@bpasero 👍. As it happens, I'm currently experiencing a 100% spike in the file watcher process (no output from the file watcher though). Is there something I can do to help debug this?

[bpasero]

A reliable repro with code I can clone myself.

[levrik]

I'm seeing the same issue as @cpojer since likely 1.92.0. I have no idea what triggers it so far. I'll try to observe when it starts to happen.

[morganick]

@bpasero I'm also running into this issue on 1.92.1 (Universal) I found that there was a Code Helper process stuck at 100% CPU. After killing that process, things came back to life.

[levrik]

VS Code became unusable for me. The merge conflict editor is showing me outdated file contents, complains about overwriting changes then (which makes sense as on disk the contents are different than what VS Code shows me). The source control view needs manual refreshes all the time. I need to restart the TS server every time I create a new file, move a file or delete a file for it to pick up these changes. Auto-import is broken very often due to that.

I didn't manage to find out when exactly it starts yet. Couldn't find anything interesting in VS Code logs. I tried disabling letting TS use VS Code's file watcher (typescript.tsserver.experimental.useVsCodeWatcher) as suggested. Let's see if this helps.

I can only point out that this issue doesn't appear immediately. I have to use VS Code actively for maybe 30 minutes or so until things start to break. Didn't manage to reproduce it while not doing real work so it's difficult to investigate.

[morganick]

@levrik I'm having a similar experience. I find the git integration unreliable. I've turned off the commit graph visualization to see if it helps. I haven't found what triggers this yet.

[lszomoru]

@morganick, please update to the newly released version (1.93) as the source graph was moved out of the main "Source Control" view.

[rickbrenn]

I've been running into this issue frequently along with several co-workers. As mentioned above, at some point during my normal workflow the fileWatcher process hits 100 CPU in the VSCode Process Explorer and further git/file changes are no longer reflected in VSCode until you reload the window.

After turning on the file watcher logging mentioned it seems to be related to pnpm and the typescript watcher. Whenever the issue happens the console is spammed with symlink renaming logs from inside the node_module folder and deleting/restoring backups. I'll try and capture it happening live since it happens frequently (about every 10 minutes or so) but there doesn't seem to be a specific trigger. Usually it happens when switching branches (which causes a lot of file updates at once) but this latest time I had a single file open, all logs cleared, and randomly while scrolling the file the logs went crazy and the CPU went to 100 and stayed there.

I'll continue to debug and report back with more info, specific logs.

[bpasero]

@rickbrenn do you have steps for me to reproduce, i.e. is the repo open source?

[levrik]

@rickbrenn I guess that's what is happening for me as well. Happens most of the time when switching branches, doing interactive rebases or something similar which tends to touch a lot of files. Also using PNPM. Sadly I couldn't find anything useful in logs so far but I also didn't turn on logging for the file watcher logging as you mentioned. I'll try that as well.

[levrik]

It just happened again for me. File watcher logs are spammed (log lines are sometimes not even 1ms apart) by things like this:

2024-09-10 16:27:17.378 [trace] [File Watcher (node.js)] reusing an existing recursive watcher for /Users/levrik/code/<redacted>/node_modules/.pnpm/@material-ui+core@4.12.4_@types+react@18.3.5_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/@material-ui/core/StepContent/package.json

It seems like it tries to re-watch every single file it knows about. I'm seeing a lot of package.json files from within node_modules but also .git and other things. I was doing an interactive rebase at the time.

After spamming the logs, it goes into 100% CPU usage deadlock. No more logs from file watcher at this point.

[rickbrenn]

@bpasero Unfortunately it's not open source so I cannot share but I might be able to replicate a repo with similar attributes for testing/reproducing the issue. It is a large monorepo with a lot of dependencies using pnpm which I assume is the factors needed for reproducing the issue since it seems to be because of the watcher watching/updating for every dependency in the node_modules folder.

I am able to confirm that the typescript.tsserver.experimental.useVsCodeWatcher setting does fix the issue. Interestingly I have not had the issue occur today even after turning that setting back on. Maybe it only starts occurring after some 'wear and tear' 😆 .

When the issue happens I see tons of logs in the console like this one:

log.ts:399 TRACE MainThreadFileSystemEventService#$watch(): request to start watching correlated (extension: vscode.typescript-language-features, path: file:///Users/rick-brenn/Documents/projects/<redacted>/node_modules/.pnpm/streamsearch@0.1.2/node_modules/streamsearch/package.json, recursive: false, session: 0.7449346843230897)

and this one:

log.ts:399 TRACE MainThreadFileSystemEventService#$unwatch(): request to stop watching (session: 0.8481027998060857)

Then in the filewatcher output panel there are tons of logs like this one:

2024-09-09 16:23:35.039 [trace] [File Watcher (parcel)] correcting a path to watch that seems to be a symbolic link or wrong casing (original: /Users/rick-brenn/Documents/projects/<redacted>/packages/<redacted>/node_modules/csvtojson, real: /Users/rick-brenn/Documents/projects/<redacted>/node_modules/.pnpm/csvtojson@2.0.10/node_modules/csvtojson)

where it seems to be changing all the symbolic links from the individual monorepo package's node_modules to the root node_modules.

[rickbrenn]

Additionally something I noticed is that when running the 'reload window' command to fix the issue, it can occur during reload which I then have to reload the window again until it doesn't. I assume that is because when it starts up the watcher it has to start watching all of those files in node_modules which can trigger it.

[cpojer]

Just summarizing, the evidence so far points at the issue being with pnpm, likely with how it links and lays out node_modules. Setting typescript.tsserver.experimental.useVsCodeWatcher to false fixes the issue for me and many others. When I turn on the experimental watcher, the issue reappears almost immediately.

[bpasero]

ℹ I would appreciate if people impacted here could try out our latest insiders build (commit c4efe1dc9eec4914f3076b2d954fe4fe174a5820). It includes a change to reduce the pressure of file watching from the TypeScript extension.

Steps:

• download insiders from https://code.visualstudio.com/insiders/
• configure typescript.tsserver.experimental.useVsCodeWatcher to the default value of true
• please make sure your files.watcherExclude setting does not include **/node_modules/*/**
• perform your workload that was showing issues

Happy to hear back how it goes 🙏

[zxcodes]

ℹ I would appreciate if people impacted here could try out our latest insiders build (commit c4efe1dc9eec4914f3076b2d954fe4fe174a5820). It includes a change to reduce the pressure of file watching from the TypeScript extension.

Steps:

• download insiders from https://code.visualstudio.com/insiders/
• configure typescript.tsserver.experimental.useVsCodeWatcher to the default value of true
• please make sure your files.watcherExclude setting does not include **/node_modules/*/**
• perform your workload that was showing issues

Happy to hear back how it goes 🙏

This seems to work well. Haven't tested a lot but it works well.