Extension leaves dozens of `rg` processes running until the machine is unusable

[justinas-kazanavicius]

With the extension active, VS Code built up 78 concurrent ripgrep processes. Each had been alive for over 11 minutes and each was using 40-90% CPU. Load average hit 191, and interactive shell startup went from 0.7s to somewhere between 5 and 17 seconds. Killing the rg processes fixed it instantly: runnable processes dropped from 99 to 43 and the machine was responsive again.

The search being run

All 78 were the same command:

rg --files --hidden --case-sensitive --no-require-git \
   -g **/dvc.yaml \
   -g !**/.git -g !**/.svn -g !**/.hg -g !**/.DS_Store -g !**/Thumbs.db \
   --no-ignore --follow --no-config --no-ignore-global

The parent process is Code Helper (Plugin), the extension host, so these come from the extension rather than VS Code's built-in search.

--no-ignore and --no-ignore-global switch off .gitignore, so the crawl walks into node_modules, .venv, build output and caches. --follow follows symlinks, which lets it wander outside the workspace and revisit the same trees. There is no --max-depth and no timeout, so over a large home directory a single one of these may never finish. Nothing seems to cancel or de-duplicate a search already in flight, so every new trigger stacks another crawl on top of the ones still running.

What I would expect instead

• Honour ignore files when looking for dvc.yaml, or put a --max-depth on the search.
• Drop --follow for workspace file discovery.
• Cancel the previous run before starting a new one, and hold at one concurrent rg per workspace folder.

Environment

• Extension: lakeFS.lakefs-dvc 1.3.2
• VS Code stable, Apple Silicon
• macOS Darwin 25.4.0, arm64

Measurements

$ ps -Ao etime,pid,args | grep ripgrep-universal | wc -l
78

$ ps -Ao etime,args | grep ripgrep-universal | sort | tail -1
      11:28  .../rg --files --hidden --case-sensitive --no-require-git -g **/dvc.yaml ...

$ uptime
load averages: 191.18 218.28 148.90

$ pkill -f 'ripgrep-universal/bin/darwin-arm64/rg'
# runnable processes: 99 -> 43

[mattseddon]

FWIW - I think this is being driven by calls made to the VS Code API. The extension calls workspace.findFiles to find all dvc.yaml files in the workspace. The code under the API calls ripgrep. Not really sure from a casual glance why this would happen 78 times, unless you have lots of DVC pipelines and/or sub-projects in the workspace... it has been a long time since I've worked on this project, sorry that I can't be more helpful.

[mattseddon]

TBH the project looks more or less abandoned.