change.detect can exceed MCP deadline in multi-repo workspace; summary_only is not count-only

[tiendungdev]

Summary

change(operation="detect") can exceed the MCP facade's ~59-second deadline in a multi-repo workspace even with output.summary_only=true. Narrowing the same call with options.repo makes it complete in 10–34 seconds.

This is not an index-health failure. The measured workspace reported health_score=100, clean path liveness, and a ready daemon.

Environment

• Gortex: v0.63.8+2a33f3d
• Host: Windows 11
• MCP client: Codex 0.150.1
• Workspace: 4 near-identical linked worktrees/repositories
• Daemon snapshot: 10,004 files, 535,510 nodes, 2,808,466 edges
• Connected MCP sessions at snapshot: 22
• Daemon state: ready; memory 291 MiB; 111 goroutines

No source, repository content, or raw pprof output is attached.

Reproduction

Broad workspace call:

{
  "operation": "detect",
  "source": {"scope": "all"},
  "output": {"summary_only": true}
}

Observed after approximately 59 seconds:

tool "change" exceeded its 58.997s deadline and was abandoned

Repo-scoped calls against the same daemon and dirty tree:

{
  "operation": "detect",
  "source": {"scope": "all"},
  "options": {"repo": "domain-manage"},
  "output": {"summary_only": true}
}

Completed in 10.309 seconds.

Changing only the scope to unstaged completed in 34.037 seconds. The variance is consistent with concurrent/background contention, but both repo-scoped calls stayed within the MCP deadline.

Per-repo controls:

• clean linked worktree: 0.48 seconds;
• dirty documentation worktree: 10.67 seconds;
• another clean linked worktree: 0.46 seconds.

analyze(kind="retrieval_log", options:{repo:"domain-manage"}) reported for the latest 5,000 queries:

change n=423 p50=238.4ms p95=143003.7ms

The p95 is over twice the MCP deadline.

Index/daemon controls

workspace(operation="index") completed in milliseconds and reported:

health_score: 100
path_liveness.clean: true
orphan_files: 0
resolution_regressions: 0
edges_ok: true

gortex daemon status reported the daemon as ready. A graph-wide analyze health and workspace graph call also exceeded the same deadline, which points to broad graph/store work or contention rather than a git diff failure specific to change.detect.

All detect scopes reported that they read tracked git diff only. Untracked .codex-worktrees directories were therefore not the cause.

summary_only observation

Successful responses with summary_only=true still contained the complete changed_symbols, changed_files, and file_changes payloads. The option removed per-depth row lists but did not avoid:

• Git diff collection;
• range-to-symbol lowering;
• reach traversal;
• materialization/serialization of changed symbols.

Therefore summary_only is useful for response shaping but does not currently provide a count-only fast path.

Retry behavior

The timeout response says work may continue in the background. Retrying the same broad request immediately three times can therefore stack expensive work and amplify contention. A later repo-scoped request succeeds, so restarting/reindexing a healthy daemon is not an appropriate first response.

Requested improvements

1. Current-repo default or hook scoping

   • Default change.detect to the current repo when a session cwd resolves unambiguously, or make the Codex post-edit hook pass the explicit repo selector.
   • Preserve an explicit workspace-wide option for callers that need it.

2. True count-only output

   • Add an output mode that avoids materializing changed_symbols and per-symbol reach rows when only counts/risk/file names are required.
   • Alternatively clarify that summary_only is response-only and add a separate compute-short-circuit field.

3. Deadline cancellation

   • Propagate the MCP context cancellation through Git diff/lowering/reach work so an abandoned request does not continue consuming graph/store capacity.

4. Phase timing diagnostics

   • Return or locally log bounded timings such as git_diff_ms, lower_ms, reach_ms, serialize_ms, selected repo count, seed-symbol count, and whether the reach index fell back to a live graph walk.

Current workaround

After the first timeout, do not retry the broad call immediately. Check index health, then retry once with both an explicit options.repo and the narrowest required source.scope. If that still times out, use already-known symbol IDs for targeted impact/tests/guards/contracts and record the detect timeout rather than claiming full-workspace absence.

[tiendungdev]

Follow-up: controlled before/after on the same build (v0.63.8+2a33f3d), same host.

After shrinking the workspace from five near-identical repos/worktrees (daemon snapshot: 12,504 files, 669,560 nodes, 3,509,811 edges) to a single repo (workspace index: 3,058 files, 148,117 nodes, 1,398,981 edges; health_score=100 in both states), the identical broad call — {"operation":"detect","source":{"scope":"all"},"output":{"summary_only":true}} — now completes within a few seconds (not precisely instrumented, well under the ~59 s deadline) and returns the same four dirty files. This confirms the latency tracks workspace membership/graph size rather than any index defect, and supports requested improvement #1.

Three additional observations from performing the shrink:

1. workspace_admin.untrack also exceeds the ~59 s MCP deadline. On the loaded 5-repo daemon, two attempts timed out and the repo list was unchanged 60+ s later. On a freshly restarted (lighter) daemon, the same call timed out at ~59 s but the removal landed in the background within ~90 s. Long-running control operations may deserve async/job semantics or progress reporting (related to ci(deps): bump crazy-max/ghaction-virustotal from 4 to 5 #3, cancellation propagation).
2. A repo tracked at runtime (MCP workspace_admin.track from another session) reappeared in the workspace after being removed from config.yaml and restarting the daemon; it required an explicit runtime untrack as well. If store-persisted runtime tracking is meant to take precedence over the config file across restarts, documenting that would help; if not, I can open a separate issue.
3. Post-restart warmup that pruned the four removed repos took ~52 minutes (vs ~12.6 minutes for a normal warmup on this corpus), with the FTS doc count fluctuating during the prune. Bounded phase timings (ci(deps): bump softprops/action-gh-release from 2 to 3 #4) would make this phase observable.