Repository navigation
Watcher can miss a live edit in a newly attached project (flaky lifecycle test removed) #1979
Description
What happened
test-int/mcp/test_new_project_watch_lifecycle.py::test_new_project_copied_files_and_live_changes_are_searchable failed intermittently in CI with TimeoutError at line 83 (latest: main 1e8e64c, run 40970750756; earlier occurrences are noted in #1955). It is removed in the linked PR because it kept failing builds.
The test, through the real MCP lifespan and native watcher, with ignored .watch-noise writes every 50 ms:
- creates a project with
bm_project(command="create") - copies
inbox/copied.mdin and pollsbm_searchforunicorn— this passes: the attach backfill indexes the copied file - rewrites the same file with
narwhaland polls for 45 s — this times out
So the project was attached and indexed, and a later edit to the same file was not indexed within 45 s.
Open question
Is this only the test, or can the watcher drop a live edit after attach? Candidates:
- The edit lands while the cycle is still in the post-attach catch-up (
watch_unfiltered,yield_on_timeout), and the batch is consumed or filtered without reachinghandle_changes. - A reload restart (
watch_project_reload_interval = 1in the test) closes the native watcher with the edit still buffered ([BUG] Watcher reload cycle drops file events pending at the restart #1852 covered restarts; this would be a remaining window). - A failed batch is logged and dropped until the next change (fix(core): own startup index tasks and remove flaky test causes #1967 notes the indexer write can hit the same race), and the test never changes the file again.
Production impact, if real: an edit made in the first seconds after a project is added is not indexed until the file changes again or a reindex runs.
Coverage after removal
tests/index/test_watch_new_projects.py still covers attach backfill and live writes with the real native watcher (test_real_quiet_watcher_backfills_then_handles_live_writes) plus reload/restart/catch-up behavior. What is no longer covered end to end: attaching while ignored-file activity continues (the #1866 case) through the MCP lifespan. A replacement should be deterministic, e.g. wait on the watcher's batch-handled signal instead of polling search under a deadline.
🤖 Generated with Claude Code
Activity
claude commentedon Oct 29, 2026
Claude finished @phernandez's task in 14s —— View job
Triage
watch_unfiltered/yield_on_timeout), a reload restart dropping a buffered edit, and a failed batch dropped until the next change.Duplicates: I searched for duplicates and found none. The issue is related to #1955, #1866, #1852 and #1967, which it already cites.
Reproduction: The issue already describes how to reproduce it. The removed test is
test-int/mcp/test_new_project_watch_lifecycle.py. It creates a project, copies a file in, rewrites it, and polls search for 45 s. It runs withwatch_project_reload_interval = 1and ignored writes every 50 ms.Suggested first step for whoever picks this up: Write a deterministic reproduction that waits on the watcher's batch-handled signal instead of polling search. Use it to tell apart "edit consumed or filtered during catch-up", "buffered edit lost on reload restart", and "failed batch logged and dropped". That will show whether this is a product bug or only a test problem.
No code was changed.
test(sync): remove the flaky new-project watch lifecycle test