Ignore PathNotFoundException when watching subdirs #2181
Conversation
Watching subdirectories is inherently racy with file-system modifications so watcher must be prepared for `Directory.watch` to fail with `PathNotFoundException`.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request addresses a race condition in the Linux directory watcher where a PathNotFoundException could be thrown if a subdirectory is deleted after being discovered but before a watch is established on it. The change correctly handles this by catching and ignoring the exception, which also resolves a long-standing TODO. The implementation using a StreamTransformer is appropriate. The pull request also includes a version bump and updates to the changelog, including a fix for a typo, which are all correctly handled. I've added one suggestion to add a specific test case to ensure this fix is robust against future regressions.
PR HealthBreaking changes ✔️
This check can be disabled by tagging the PR with Changelog Entry ✔️
Changes to files need to be accounted for in their respective changelogs. This check can be disabled by tagging the PR with Coverage ✔️
This check for test coverage is informational (issues shown here will not fail the PR). This check can be disabled by tagging the PR with API leaks ✔️The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API.
This check can be disabled by tagging the PR with License Headers ✔️
All source files should start with a license header. Unrelated files missing license headers
This check can be disabled by tagging the PR with |
2 participants
Watching subdirectories is inherently racy with file-system modifications so watcher must be prepared for
Directory.watchto fail withPathNotFoundException.This is revealed when running tests against this CL which changes timing of certain events slightly:
onDoneforFileSystemEntity.watch()stream is now delayed by few turns of the event loop while underlying watcher is being destroyed, previously it used to fire immediately which hid away some of the inherent races in the code.