Metro seems to leave orphaned watchman watches frequently

[swrobel]

Do you want to request a feature or report a bug?
Bug

What is the current behavior?
Frequently, when running my app via yarn ios, the launched metro process immediately shows the following:

watchman warning:  Recrawled this watch 15 times, most recently because:
MustScanSubDirs UserDroppedTo resolve, please review the information on
https://facebook.github.io/watchman/docs/troubleshooting.html#recrawl
To clear this warning, run:
`watchman watch-del '/Users/swrobel/Code/bakesy-apps' ; watchman watch-project '/Users/swrobel/Code/bakesy-apps'`

If the current behavior is a bug, please provide the steps to reproduce and a minimal repository on GitHub that we can yarn install and yarn test.
Unfortunately there doesn't seem to be an easy repro as I'm not sure what triggers these orphaned watchman processes (or at least that's my assumption of what's happening)

What is the expected behavior?
Metro avoids these situations altogether, or barring that, automatically clears the old watches and creates new ones upon startup instead of just printing this message which isn't really relevant as far as I can tell (would running watchman watch-project in a separate terminal even work correctly?)

Please provide your exact Metro configuration and mention your Metro, node, yarn/npm version and operating system.
yarn 1.22.18
node 16.15.0
Metro 0.67.0

metro.config.js:

/**
 * Metro configuration for React Native
 * https://github.com/facebook/react-native
 *
 * @format
 */

// Work around Metro bug with cjs files
// https://github.com/facebook/metro/issues/535#issuecomment-970443661
const defaultSourceExts = require('metro-config/src/defaults/defaults').sourceExts

module.exports = {
  transformer: {
    getTransformOptions: async () => ({
      transform: {
        experimentalImportSupport: false,
        inlineRequires: true,
      },
    }),
  },
  resolver: {
    sourceExts: process.env.RN_SRC_EXT
      ? [...process.env.RN_SRC_EXT.split(',').concat(defaultSourceExts), 'cjs']
      : [...defaultSourceExts, 'cjs'],
  },
}

[robhogan]

Hi @swrobel, thanks for the report. This is probably not directly a Metro issue but we've seen something similar internally. Is this something that's just recently started occurring, as far as you're aware?

Could you also let us know your watchman --version and the output of watchman debug-status (may not be supported on your version) shortly after this recurs?

would running watchman watch-project in a separate terminal even work correctly?

In principle, yes, although I've no evidence to say it would solve this particular problem. Watchman runs as a single background daemon, and both Metro and the watchman CLI communicate with it over sockets. The suggested commands just "reset" the watch on the given directory, but at best that's a temporary fix if you're seeing this recurrently. Essentially Metro is reporting that Watchman is frequently falling out of sync with the file system. If there's anything else you can think of about your environment that might cause that (virtual / transient / remote file mount etc), that might be helpful.

[swrobel]

This is now occurring on just about every yarn react-native run-ios on Metro 0.70.3. I'm not sure when it started happening ... maybe when I switched to an M1 Macbook, but it's quite persistent. I only have a single react native app that I ever run on my machine.

$ watchman --version
2022.07.04.00

$ watchman debug-status
ROOTS
-----
/Users/swrobel/Code/bakesy-apps
  - fstype: apfs
  - watcher: fsevents
  - uptime: 114149 s
  - crawl_status: crawl completed 361797ms ago, and took 1739ms
  - done_initial: true

CLIENTS
-------
  - state: dispatching command
  - state: waiting for request

[ArindamRayMukherjee]

Hi, I am hitting this exact same issue. Any insights?

[dcorbin]

I see this frequently. I CTRL-C metro, and then restart it. Maybe it shouldn't be necessary, but it feels right for more completely clean build. Or I have to switch projects, which leads me to want to stop metro. Why there is no "q to quit" option is beyond me.

[raid5]

Having this issue as well in 2024

[sandipndev]

Same issue very often, any way to fix this?

[NorseGaud]

I've seen this for more than 2 years

[dcorbin]

My assumption (and that is all it is) is that when Metro is forcefully terminated it's not unwinding the watch request it made.

[NorseGaud]

Maybe, but I don't forcefully terminate it. I just do a normal ctrl+c and it should cleanly shut down

[dcorbin]

I consider CTRL-C forceful. It's "an interrupt", rather than it just being a command to execute.

[smileart]

2026, can confirm that this is still an issue.