macOS: FsEventWatcher stops delivering callbacks after first batch on GitHub Actions CI (9.0.0-rc.4)

[botirkhaltaev]

Environment

• notify: 9.0.0-rc.4
• Platform: macos-latest GitHub Actions
• Backend: FsEventWatcher (latency: 0.0, flags: FileEvents | NoDefer | WatchRoot)

Symptom

After the first callback successfully delivers file-creation events, a subsequent file modification (or second file creation) does not trigger a second callback within 10-20 seconds. The watcher is configured with latency: 0.0 and kFSEventStreamCreateFlagNoDefer, so artificial coalescing should not apply.

Linux inotify delivers callbacks reliably for every change.

CI logs

First build (sequential writes: https://github.com/botirk38/sift/actions/runs/26710240469/job/78719001097?pr=68 — first callback for creation arrived, second callback for modification never arrived within 10s.

Workaround

Write all file changes at once so they land in a single FSEvent batch.

Related

• Windows issue Windows: ReadDirectoryChangesWatcher misses file creation in recursive temp-dir watch on GitHub Actions (9.0.0-rc.4) #935: ReadDirectoryChangesWatcher has a similar symptom (missed creation events), likely a different root cause.

Reproduction

use notify::{RecursiveMode, Watcher};
use std::sync::mpsc;
use std::time::Duration;
use tempfile::TempDir;

let dir = TempDir::new().unwrap();
let (tx, rx) = mpsc::channel();
let mut w = notify::recommended_watcher(move |res| {
    if let Ok(e) = res { let _ = tx.send(e); }
}).unwrap();
w.watch(dir.path(), RecursiveMode::Recursive).unwrap();

// First write — callback arrives (latency ~several seconds on CI)
std::fs::write(dir.path().join("a.txt"), "first").unwrap();
match rx.recv_timeout(Duration::from_secs(15)) {
    Ok(_) => println!("first event ok"),
    Err(e) => { eprintln!("no first event: {e:?}"); return; }
}

// Second write — callback may never arrive within 10-20s
std::fs::write(dir.path().join("b.txt"), "second").unwrap();
match rx.recv_timeout(Duration::from_secs(15)) {
    Ok(_) => println!("second event ok"),
    Err(e) => eprintln!("no second event: {e:?}"),
}

[hiSandog]

The reproduction would be especially diagnostic if it logs the FSEvent stream callback flags and event IDs for both writes, and inserts an explicit filesystem sync between them. Comparing latency: 0.0 with a small nonzero latency and toggling NoDefer could reveal whether the zero-latency stream is being scheduled incorrectly rather than losing the underlying event.