aft_inspect: rust-analyzer diagnostics reported as errors while cargo is clean

[iceteaSA]

aft_inspect reports hundreds of Rust errors on a tree that cargo check compiles without complaint.

Hit this on this repo an hour ago, right after syncing 23 commits:

aft_inspect(sections: "diagnostics", scope: "crates/aft/src")
  → diagnostics: 1104 errors, 259 warnings, 0 info, 123 hints
    (incomplete — servers: none reported)

  crates/aft/src/ast_grep_hints.rs:343:1   error expected bool, found ()
  crates/aft/src/ast_grep_lang.rs:151:33   error expected &'static [&'static str], found &[&'static str; 3]
  crates/aft/src/bash_background/output.rs:117:49  error cannot index into a value of type `&str`
  …

cargo check --bin aft
  → Finished `dev` profile in 0.13s

cannot index into a value of type &str on ordinary indexing, and expected bool, found () on code that compiles, are not real. The status bar sat at E17 off the back of it.

Note servers: none reported in that output — rust-analyzer hadn't finished initializing. A second deployment reports the same symptom with a different trigger: files using tracing:: macros produce error storms while cargo, clippy, and nextest are all green, which fits proc-macro expansion being unavailable.

Both roads lead to the same place: rust-analyzer answers before it can answer correctly, and aft_inspect presents that as errors with no signal that the analyzer wasn't ready.

The practical damage is calibration. An agent that sees E1104 against a clean cargo check learns to ignore aft_inspect on Rust, and then misses the run where the errors are real.

Suggested shape

Any of these would help, roughly in order of preference:

• Don't count diagnostics toward E/W when the server set is incomplete or reports nothing — surface them as pending instead. The response already knows this; (incomplete — servers: none reported) is right there in the output.
• Mark diagnostics from a not-yet-ready analyzer as provisional in the detail lines.
• Failing either, a line in the Rust docs that the compiler is authoritative and aft_inspect diagnostics are a fast approximation.

The tool's own guidance already says its diagnostics are "a fast checkpoint, not the authority" — this is asking the output to reflect that when the analyzer is demonstrably not in a position to judge.

Happy to write the PR if you have a preference among those. The first seems most in keeping with the honest-reporting convention in protocol.rs: the incomplete-server state is already tracked, it just isn't gating the error count.

[alfonso-aft]

Confirmed at source, and your first option is the right one — the incomplete-server state is tracked but never gates the counts. Two things are landing for this:

1. Generic honesty: when a diagnostics scan is incomplete or pending, its counts become provisional — excluded from the top-level error/warning totals and the status bar (which keeps its last authoritative numbers), with the detail rows kept as leads under a provisional marker. Complete and no-server scans are unchanged.

2. rust-analyzer readiness: we'll consume experimental/serverStatus (the same quiescence signal VSCode uses, which we currently ignore) so diagnostics published before the analyzer first reaches quiescent are flagged provisional at the store level and refreshed once it settles. That covers both your after-sync storm and the proc-macro/tracing variant on the other deployment.

The calibration framing is exactly why this is worth the fix: E1104 against a clean cargo teaches agents the wrong lesson permanently. Appreciate the offer to PR — the readiness plumbing touches enough LSP internals that it's cheaper on our side, but the report did the hard half.

[iceteaSA]

experimental/serverStatus is a better answer than what we proposed — gating on incompleteness treats the symptom, quiescence removes the window entirely. Fine by us that it stays in-house.

The after-sync trigger is easy to reproduce if you want a check while developing it: sync a batch large enough to invalidate the analyzer's state (32 commits did it here), then run aft_inspect on a Rust scope before it settles. We got 1104 errors against a clean cargo check, with servers: none reported in the same response. Happy to run your branch against it once there's something to test — this box reproduces it reliably.

One adjacent case, in case it's in scope for the generic honesty pass. aft_gather returns callgraph store is building in the background; retry shortly to the caller, but nothing about that rejection reaches the log — grep -c on the message across a full session log returns 0. We spent a while this morning working out why gather kept declining, and had to infer it from cold-build lines and generation files on disk:

07:46:04  callgraph store scheduled for background rebuild after watcher overflow
07:46:27  cold_build (chunked): files=1412 nodes=20529 edges=48009 ms=10133
07:47:14  cold_build (chunked): files=1412 nodes=20529 edges=48009 ms=11708

The rebuilds were logged; the rejections they caused were not. Same family as this issue — the state is known internally and not surfaced — but a different subsystem, so tell us if you'd rather have it as its own issue and we'll write it up separately.

(Unrelated aside, since it was our own doing: back-to-back bun install / bun run build / cargo build overflowed the watcher and forced those full rebuilds. Correct conservative behavior, just worth knowing that heavy build activity resets the index.)

[alfonso-aft]

Released in v0.49.2.