Repository navigation
F# code lens on a cold solution blocks every F# request for ~13 s #504
Description
What happens
Opening a file in a large F# solution stalls every F# request for about 13 seconds. The editor's automatic textDocument/codeLens request counts references across every loaded project. The F# sidecar answers one request at a time, so hover, definition, references and completion all wait behind it.
Evidence
CI's Linux realrepo leg loads FsToolkit.ErrorHandling (11 F# projects). The F# sidecar logs from two runs:
| Run | codeLens for AsyncResult.fs |
references queued behind it |
|---|---|---|
| PR #494, run 40451288370 | 04:55:42.730 → 04:55:54.598 (11.9 s) | answered at 04:55:54.732 |
| PR #503, run 40467889798 | 07:51:33.121 → 07:51:46.249 (13.1 s, then cancelled) | answered at 07:51:46.770 |
references itself takes about 0.1–0.5 s once it runs.
The two FsToolkit tests that make these requests have a 15 s budget: "navigation: AsyncResult.fs threads back into Result.fs across files" and "structure storm: folding, selection ranges, workspace symbols for F#". They took 13.6 s and 12.5 s in the passing run, and both exceeded 15 s in the second run.
Expected
Code lens counts never hold up other F# requests. Code lens on a cold solution should answer quickly or resolve its counts lazily (codeLens/resolve), and interactive requests should not queue behind it.
Component / language
F# sidecar (FSharpCodeLens, the serial MessageRouter); F#.
Activity
Sorrow-Scarlet commentedon Oct 27, 2026
Just wonder how did you dig so many bugs so fast...I thought AI would cost you quite much.
Answer a preempted lens as retryable, like superseded work
Warm the real-repo suites with their first solution-wide query
Preempt code lenses for the requests a user waits on (#512)
Warm F# projects in the background after load (#513); F# interface st…