Watcher coverage decays over a working day: watches only ever shrink, a directory rename is untested, and index_coverage tells you to retry in a second #145

New issue

Closed

opened 2026-09-05 12:53:44 +02:00 by buildagent · 0 comments

buildagent commented

2026-09-05 12:53:44 +02:00

Member

Found by a production-readiness review. This is #82's shape, in the tool an agent calls specifically to diagnose a missing file.

The decay

Watches are non-recursive and only ever shrink. mv src/foo src/bar leaves orphan rows at the old path and nothing at the new — for up to 30 minutes (the reconcile interval), with no disclosure, or forever with reconcile_interval_min = 0.

There is no directory-rename test in the tree. All three fs::rename watcher tests rename files. The failure mode with the widest blast radius is the one shape not covered.

The disclosure is actively wrong for this population

index_coverage returns pending with the guidance that the watcher picks new files up in about a second — retry. For a file that arrived via a directory rename, the true answer is 30 minutes, or never. The tool an operator calls to diagnose a missing file gives them the one answer that guarantees they stop looking.

Per this project's own doctrine, pending is a promise. A pending whose real horizon is a reconcile interval is a different state from a pending whose horizon is a debounce, and they must not render identically.

Ask

A directory-rename test — this is the missing coverage, and it should fail today.
Re-watch on directory creation/rename, or an honest statement that coverage is reconcile-bound with the interval named in the payload.
index_coverage's pending must distinguish "the watcher will get this in ~1 s" from "this is only reachable by the next reconcile, at " from "reconcile is disabled, this will never arrive".

#82 (Linux dynamic re-watch)
The reconcile that closed the periodic half shipped in v0.3.1; this is the other half.

🤖 Generated with Claude Code

https://claude.ai/code/session_01K1zj5VcFJvJt3pQxe9259K

Found by a production-readiness review. This is #82's shape, in the tool an agent calls specifically to diagnose a missing file. ## The decay Watches are **non-recursive and only ever shrink**. `mv src/foo src/bar` leaves orphan rows at the old path and nothing at the new — for up to 30 minutes (the reconcile interval), **with no disclosure**, or forever with `reconcile_interval_min = 0`. **There is no directory-rename test in the tree.** All three `fs::rename` watcher tests rename *files*. The failure mode with the widest blast radius is the one shape not covered. ## The disclosure is actively wrong for this population `index_coverage` returns `pending` with the guidance that *the watcher picks new files up in about a second — retry*. For a file that arrived via a directory rename, the true answer is **30 minutes, or never**. The tool an operator calls to diagnose a missing file gives them the one answer that guarantees they stop looking. Per this project's own doctrine, `pending` is a promise. A `pending` whose real horizon is a reconcile interval is a different state from a `pending` whose horizon is a debounce, and they must not render identically. ## Ask 1. A directory-rename test — this is the missing coverage, and it should fail today. 2. Re-watch on directory creation/rename, or an honest statement that coverage is reconcile-bound with the interval named in the payload. 3. `index_coverage`'s `pending` must distinguish "the watcher will get this in ~1 s" from "this is only reachable by the next reconcile, at <T>" from "reconcile is disabled, this will never arrive". ## Related - #82 (Linux dynamic re-watch) - The reconcile that closed the periodic half shipped in v0.3.1; this is the other half. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01K1zj5VcFJvJt3pQxe9259K

buildagent referenced this issue

2026-09-05 12:54:34 +02:00

code-index doctor is blind to staleness, watcher health and resolve state, and check_disk_free only fires at literally zero bytes #150

buildagent referenced this issue

2026-09-05 15:28:56 +02:00

After a schema upgrade the daemon serves for the whole re-parse from an index whose stat and hash were all invalidated — and nothing is known to disclose it #155