What issue are you seeing?
FileSearchSession can call SessionReporter::on_complete() after the directory walk finishes but before the matcher has processed its first QueryUpdated signal.
This matters to the synchronous run() path: it creates the session, starts the walker and matcher workers, then sends the query and waits for completion. The walker and caller send through different clones of the channel sender. For a fast or empty walk, WalkComplete can be received first, causing run() to return the reporter's default empty snapshot before its requested query has run.
What steps can reproduce the bug?
On main commit 315195492c80fdade38e917c18f9584efd599304, add the following regression test inside the existing file-search/src/lib.rs test module:
#[test]
fn initial_query_survives_preemption_after_session_creation() {
let dir = create_temp_tree(/*file_count*/ 40);
let reporter = Arc::new(RunReporter::default());
let session = create_session(
vec![dir.path().to_path_buf()],
FileSearchOptions::default(),
reporter.clone(),
/*cancel_flag*/ None,
)
.expect("session");
// Model the caller being descheduled after create_session returns but
// before run() can send its initial query.
thread::sleep(Duration::from_millis(100));
session.update_query("file-0039");
let snapshot = reporter.wait_for_complete();
assert_eq!(snapshot.query, "file-0039");
}
The short pause models a valid operating-system preemption at the exact boundary used by run(); the test otherwise follows the real create_session → update_query → wait_for_complete path and does not inject private work signals.
Run:
just test -p codex-file-search initial_query_survives_preemption_after_session_creation
The test fails on both the initial run and nextest retry:
left: ""
right: "file-0039"
What is the expected behavior?
Completing the directory walk should not complete a session that has not received a query. Once a query is received, the existing contract should remain unchanged: the reporter is eventually completed for that update.
Additional information
Root-cause hypothesis: matcher_worker gates completion on !status.running && walk_complete, but it does not track whether a query has ever been received. A minimal fix is to record receipt of the first QueryUpdated and require that state before reporting normal completion.
The session-based implementation originated in merged PR #9939. I searched existing issues and pull requests using the relevant file-search symbols and completion-order terms; I found related session completion discussions in that PR, but no report covering WalkComplete arriving before the first QueryUpdated signal.
I have a focused regression test and local one-commit fix ready. I would be happy to submit it if a Codex maintainer invites a PR.
What issue are you seeing?
FileSearchSessioncan callSessionReporter::on_complete()after the directory walk finishes but before the matcher has processed its firstQueryUpdatedsignal.This matters to the synchronous
run()path: it creates the session, starts the walker and matcher workers, then sends the query and waits for completion. The walker and caller send through different clones of the channel sender. For a fast or empty walk,WalkCompletecan be received first, causingrun()to return the reporter's default empty snapshot before its requested query has run.What steps can reproduce the bug?
On
maincommit315195492c80fdade38e917c18f9584efd599304, add the following regression test inside the existingfile-search/src/lib.rstest module:The short pause models a valid operating-system preemption at the exact boundary used by
run(); the test otherwise follows the realcreate_session → update_query → wait_for_completepath and does not inject private work signals.Run:
The test fails on both the initial run and nextest retry:
What is the expected behavior?
Completing the directory walk should not complete a session that has not received a query. Once a query is received, the existing contract should remain unchanged: the reporter is eventually completed for that update.
Additional information
Root-cause hypothesis:
matcher_workergates completion on!status.running && walk_complete, but it does not track whether a query has ever been received. A minimal fix is to record receipt of the firstQueryUpdatedand require that state before reporting normal completion.The session-based implementation originated in merged PR #9939. I searched existing issues and pull requests using the relevant file-search symbols and completion-order terms; I found related session completion discussions in that PR, but no report covering
WalkCompletearriving before the firstQueryUpdatedsignal.I have a focused regression test and local one-commit fix ready. I would be happy to submit it if a Codex maintainer invites a PR.