pub const HEALTH_SWEEP_INTERVAL: Duration;Expand description
How often the background sweep re-arms every currently-degraded
path, self-healing a watch that failed to establish (or a prior sweep
found dead) without needing a dedicated retry loop running forever.
Deliberately scoped to degraded targets only, not every subscribed
path — an earlier version of this sweep re-issued watch()
unconditionally on everything, every tick, to also catch a silently
dead healthy-looking watch (inotify instance-limit churn, a watched
directory deleted and recreated at a new inode, a flaky network mount).
That cost more than it bought: notify 7.0.0’s Windows backend leaks a
File + Semaphore handle pair on every redundant watch() call (no
cleanup of the previous entry), and even with an unwatch() first to
avoid the leak, the gap between unwatch() and watch() drops event
coverage for consumers with no reconciliation backstop of their own
(config_watcher_fs, EditorFileWatcher, MediaFileWatcher). See
pool.rs’s sweep() and
docs/status/STATUS_FS_WATCH_SWEEP_HANDLE_LEAK_2026_08_22.md for the
full history and the accepted trade-off (a truly silent death of an
already-healthy watch is no longer self-healed by this sweep).