Repository navigation
Flaky CI: watcher lifecycle integration test and Postgres refresh negative control #1955
Description
Two tests failed CI on PRs that don't touch their code during the 1.0 merge run (2026-10-29), and passed on re-run.
test-int/mcp/test_new_project_watch_lifecycle.py::test_new_project_copied_files_and_live_changes_are_searchable
- Added in fix(sync): catch up newly watched projects during ignored activity #1866. Times out (
TimeoutErrorinsideasyncio.timeout) or hangs in teardown until pytest's 120s timeout. - Seen on fix(core): normalize OpenAI-compatible embedding vectors #1948 (embedding normalization, run 40822849897, SQLite integration shard 2/2) and feat(cli)!: remove legacy cloud sync and bisync #1953 (cloud sync removal, run 40824219606, SQLite integration shard 2/2, Python 3.12).
- The [BUG] Watcher reload cycle drops file events pending at the restart #1852 work (fix(sync): keep file events across watcher reloads #1951) also found that
tests/services/test_initialization.pyand this test fail together in one pytest process: a fake_CapturedTaskleft in the module-global_initial_index_tasksis gathered by this test's teardown (TypeError). That may or may not be the CI cause.
tests/services/test_search_refresh_concurrency.py::test_negative_control_relation_rows_collide_without_the_tolerance
- Postgres unit shard 4/6 on feat(cli)!: remove legacy cloud sync and bisync #1953:
AssertionError: without the tolerance, overlapping refreshes were expected to collide. - A negative control that requires a race to happen is timing-dependent on shared runners.
Fix direction
- Lifecycle test: find the wait that can outlast its deadline under load; isolate
_initial_index_tasksper test. - Negative control: force the overlap deterministically (e.g. an explicit barrier between the two refreshes) instead of relying on timing, or drop it if the positive tests cover the tolerance.
🤖 Generated with Claude Code
Activity
claude commentedon Oct 29, 2026
Claude finished @phernandez's task in 14s —— View job
Triage
Duplicates: None found. #940 covers a similar class (timing-sensitive tests) but different tests, and it is closed.
Notes
test-int/mcp/test_new_project_watch_lifecycle.py): the issue already names a likely cause. The module-global_initial_index_tasksis shared across tests, and a fake_CapturedTaskfromtests/services/test_initialization.pycan be gathered in this test's teardown. That would explain theTypeErrorand may also explain the teardown hang. Theasyncio.timeoutfailures seen on SQLite shard 2/2 could be a separate load-sensitive wait, so fix both: isolate the task set per test and review the wait deadlines.tests/services/test_search_refresh_concurrency.py): it asserts that a race happens, so it depends on timing. The issue's suggestion of an explicit barrier or event between the two refreshes is the right fix. If the positive tests already cover the tolerance, dropping the control is also fine.No reproduction steps are needed. The CI run links are in the issue. I've stopped at triage and made no code changes.
phernandez commentedon Oct 29, 2026
Two more failures on 2026-10-29, now with a third symptom:
bm_searchraisingsqlite3.OperationalError: vtable constructor failed: search_indexinside the watcher lifecycle test.test_new_project_copied_files_and_live_changes_are_searchable. In the same run,test-int/test_sqlite_lifecycle_integration.py::test_file_sqlite_concurrent_writes_commit_and_disposealso failed with an OperationalError.A virtual-table constructor failure on an FTS5 table points at the search_index being created or dropped concurrently while another connection opens it. The watcher's new-project catch-up may be (re)creating search tables while the test searches.
fix(core): own startup index tasks and remove flaky test causes (#1967)
phernandez commentedon Oct 29, 2026
Another occurrence on main at 1e8e64c (run 40970750756, SQLite integration shard 2/2):
test_new_project_copied_files_and_live_changes_are_searchabletimed out at line 83, thenarwhalloop. The first loop (copied file indexed after attach) passed, so the project was attached and only the later live edit was missed. Same symptom as described above; the next main run (fb90bbb) passed.test(sync): remove the flaky new-project watch lifecycle test