Repository navigation
Single-file grep pair waits without progress before returning no matches #1531
Description
Read-only CLI audit observation on a Linux build node. These two single-file literal searches were executed sequentially after an outline that had already returned:
prod-code grep 'canary|secret|TLS_KEY_ENV|AUTH_TOKEN' --path crates/prod-code-gateway/tests/e2e_remote_exec.rs
prod-code grep 'canary|secret|TLS_KEY_ENV|AUTH_TOKEN' --path crates/prod-code-gateway/tests/exec_shim.rsThe command group remained live after the initial 10-second observation and another 5-second wait, with no grep output or progress message. It eventually exited 0 and printed No matches found for each search. No exact end-to-end duration or individual-query latency was captured, so the observation does not attribute the delay to one file or a particular subsystem. No retry was run.
Expected: bounded single-file text searches should complete promptly, or show actionable progress explaining placement/index/sync waits. Investigate the existing recorded execution before adding retries or broad load tests. This was an audit tool observation, not a benchmark or a correctness claim about the empty results.
Environment
- client: prod-code 0.3.41 (commit 9a21810) on macos aarch64
- node: linux x86_64 (prod-code 0.3.41, commit 9a21810), engines: rust (ra_ap_ide), go (gopls), cpp (clangd), python (basedpyright-langserver), typescript (tsc --lsp), java (jdtls), kotlin (kotlin-language-server), csharp (omnisharp), zig (zls), scala (metals), generic-lsp
Filed with prod-code report-issue.
Activity
alex09x commentedon Oct 26, 2026
A related bounded navigation observation, without a retry:
The command eventually exited 1 with:
This output supplies an actionable capacity hint; I am not claiming a specific engine defect or separating sync/load/queue time. The file was inspected through the already available immutable Git diff afterward. No cluster restart, alternate-node retry, test/build or duplicate query was launched. The prior grep latency observation remains unchanged; this adds an exact terminal timeout rather than inferring a hung process from silence.
alex09x commentedon Oct 28, 2026
PR #1712 adds a local-ripgrep fast path for an explicit file inside the checkout. The new public-tool test reproduces the remote wait with a 2 s mock exec delay: before, the empty search returned after 2.01 s; after, both empty and matching searches return locally in 0.06 s and no remote exec is sent. The remote path remains for directory/workspace searches and as fallback. The issue will close when the PR merges.