Skip to content

fix: keep macOS watchers within FSEvents path limits - #128

Closed
masonjames wants to merge 1 commit into
bartolli:mainfrom
masonjames:fix/batch-watch-registration
Closed

masonjames wants to merge 1 commit into
bartolli:mainfrom
masonjames:fix/batch-watch-registration

Conversation

@masonjames

Copy link
Copy Markdown
Contributor

Description

Fixes #126. macOS now watches registered roots recursively, avoiding FSEvents' watch-path limit; path additions use notify's batch API. Other platforms retain non-recursive directory selection. Existing handlers still enforce file eligibility and ignore rules.

Type of Change

  • Bug fix

Testing

  • Opt-in macOS regression: 5,000 directories, a directly contained root file, new subtree creation, edit, deletion, and an ignored file.
  • Readiness improved from about 99 seconds to 0.84 seconds. A separate MCP probe observed create/edit/delete in 0.92/0.85/2.09 seconds.
  • quick-check.sh and full-test.sh pass locally.

Checklist

  • Guidelines followed; self-reviewed; no new warnings.
  • No index-format or API changes.

The regression verifies persisted symbol changes, not just startup logs. Batching alone was insufficient above the native path limit.

@bartolli

Copy link
Copy Markdown
Owner

Thanks for the PR! I rewrote the batching logic and merged it to main (you are credited as co-author).

macOS FSEvents now restart once per batch instead of per directory. I skipped recursive roots for now to prevent exhausting inotify watches on large ignored trees. Let's test startup at 5,000 directories before revisiting.

The blocking-callback hang is still tracked separately.

@masonjames masonjames closed this Sep 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

macOS watcher startup restarts FSEvents once per directory

2 participants