Problem. Tests that actually index a project (index::session::tests::session_indexes_incrementally_and_excludes_skipped, ...::rebuild_resets_project_and_prune_counts_deleted, commands::watch::tests::filtered_reindex_touches_only_matching_changed_files, and similar) go through index_project_with_id → brain::embed_project → CodeVectorIndex::load_or_create_usearch → vector::acquire_file_lock (src/index/vector.rs ~L606, flock exclusive) on the real global vector index under ~/.codecora/cora-code/cora_index.usearch.
Effect (reproduced on develop @ 359840f+). If any other cora process on the machine holds that lock (observed: a cora scan --path crates that had been running 52 min), these tests hang indefinitely. Sampling the stuck test thread shows it parked in flock at vector.rs:606. CI is unaffected (clean runner), which is why it only shows up locally and in agent sandboxes (two agents reported unexplained hangs of cargo test). The tests also read and write the developer's real ~/.codecora index, so a test run can pollute it.
Fix. Isolate tests: point the data dir at a tempdir (CODECORA_HOME / data_dir::CODECORA_HOME_ENV already exists) via a test helper or guard, and/or let acquire_file_lock use try_lock with a timeout and a clear error. Add a guard test that a locked global index surfaces an error instead of blocking forever, and audit other tests that open open_global_index()/vector paths with the real HOME.
Introduced/exposed by tests added in #576 and #584; the underlying coupling predates them.
Problem. Tests that actually index a project (
index::session::tests::session_indexes_incrementally_and_excludes_skipped,...::rebuild_resets_project_and_prune_counts_deleted,commands::watch::tests::filtered_reindex_touches_only_matching_changed_files, and similar) go throughindex_project_with_id→brain::embed_project→CodeVectorIndex::load_or_create_usearch→vector::acquire_file_lock(src/index/vector.rs~L606,flockexclusive) on the real global vector index under~/.codecora/cora-code/cora_index.usearch.Effect (reproduced on develop @ 359840f+). If any other
coraprocess on the machine holds that lock (observed: acora scan --path cratesthat had been running 52 min), these tests hang indefinitely. Sampling the stuck test thread shows it parked inflockatvector.rs:606. CI is unaffected (clean runner), which is why it only shows up locally and in agent sandboxes (two agents reported unexplained hangs ofcargo test). The tests also read and write the developer's real~/.codecoraindex, so a test run can pollute it.Fix. Isolate tests: point the data dir at a tempdir (
CODECORA_HOME/data_dir::CODECORA_HOME_ENValready exists) via a test helper or guard, and/or letacquire_file_lockusetry_lockwith a timeout and a clear error. Add a guard test that a locked global index surfaces an error instead of blocking forever, and audit other tests that openopen_global_index()/vector paths with the real HOME.Introduced/exposed by tests added in #576 and #584; the underlying coupling predates them.