fix(mcp): report freshness with the indexer's own mtime source (#1714) - #1787

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

Thank you for tracing the Windows freshness mismatch to two different timestamp sources. I checked current main: coverage_path_freshness() converts struct stat time, which uses second precision on the Windows branch, while the index path already records cbm_path_info_utf8 nanoseconds. The incremental comparison has the same platform-dependent st_mtime fallback. That grounds both false-change paths described here.

I have labeled this as a high-priority Windows parsing and correctness bug and routed it for review. The current CI surface is green. Our review queue is full, so detailed review may take a little time. Thank you for converging the readers on the writer's existing source of truth.

Independent Windows confirmation from codebase-memory-mcp 0.10.8:

• Immediately after a cold full re-index, generation_matches was true and coverage recording was complete, but every sampled path still returned status: no_recorded_issue with freshness: metadata_changed.
• I compared the persisted file_hashes row with the live file: SHA-256, size, and the full FILETIME-derived mtime_ns matched. The mismatch was isolated to the coverage reader rebuilding the timestamp as whole-second st_mtime * 1e9.
• I reviewed commit 455e4fb: using cbm_path_info_utf8 in both coverage_path_freshness and incremental classify_files aligns both readers with semantic_manifest_hash_file, which is the writer of the stored metadata. This matches the observed root cause and also addresses the same precision mismatch in warm incremental indexing.

The PR Windows CI and regression are green. I could not independently rebuild the PR binary locally because this machine does not have the required MSYS2 CLANG64 toolchain, so this is an independent reproduction plus source-level validation, not a separate binary test.

Approved on merit, and the impact is larger than your description claims — I want to spell that out, because it strengthens the case rather than weakening it.

Verified

Both truncations are real and both are Windows-only:

• mcp.c:4725 coverage_stat_mtime_ns — #elif defined(_WIN32) returns st->st_mtime * NSEC_PER_SEC, seconds resolution.
• pipeline_incremental.c:107 stat_mtime_ns — the same #elif defined(_WIN32) branch, same truncation.

macOS uses st_mtimespec.tv_nsec and Linux st_mtim.tv_nsec, so both agree with the writer and neither is affected. Your diagnosis is exact.

And the repo already states the rule you are enforcing. src/pipeline/artifact.c:534-538:

The disk side MUST be read with cbm_path_info_utf8, because that is the [function the indexer] calls … On POSIX any lstat-based helper agrees with it, but on Windows cbm_path_info_utf8 derives mtime_ns from ftLastWriteTime.

So this is not a new convention — it is an existing, documented invariant that two readers were quietly violating. That is the cleanest possible justification for the change, and I would put that citation in the PR description.

The part you understated

You describe the pipeline_incremental.c half as "it would mark every file changed on Windows". Following it through, pipeline_incremental.c:693 is:

if (stat_mtime_ns(&st) != h->mtime_ns || st.st_size != h->size) {
    changed[i] = true;

With a seconds-truncated left side and a FILETIME-derived right side, those can only agree when the sub-second component is exactly zero. So on Windows incremental reindex has been degenerating into a full reindex on essentially every run — that is a performance defect on top of a correctness one, and on a large repository it is the more expensive of the two.

The check_index_coverage half is the worse kind of bug, though. A tool that reports nothing is annoying; a tool that reports metadata_changed for a graph indexed seconds ago actively misleads, and the documented guidance tells agents to act on it. Silent wrongness beats loud absence every time, and this was the wrong side of that.

Before merge

Please tick or explain the lint box. make -f Makefile.cbm lint-ci is unchecked in your checklist. If it failed with whole-file clang-format drift in files you did not touch, that is a known false positive — our gate requires the Homebrew LLVM clang-format, and a distro or standalone clang-format-20 reports spurious differences. Just say so and I will treat it as clean.

You are 205 commits behind main, so the green on this PR is stale and means little. Normally I would rebase it for you, but our Actions pool is badly backlogged right now (31 runs queued) and every rebase adds a full matrix to that queue, so I am deliberately holding off. I will refresh it once the queue drains, or you can rebase whenever suits you.

Nothing to change in the code. Thank you — this is a well-isolated fix to a bug that made a correctness signal actively harmful on one platform.

Merged — with an apology attached. This was approved on merit on 2026-09-02 and then sat green for eighteen days. Nothing was outstanding from you; the delay was entirely ours.

Reading it back before merging, the maintainer note from 09-02 holds up: the impact is larger than your own description claimed. coverage_stat_mtime_ns derived the timestamp from struct stat, whose Windows branch carries second precision, while the index path recorded nanoseconds from a different source. Two sources for one comparison is a bug that cannot be tuned away — it is wrong whenever the two disagree, and on Windows they disagree routinely. Taking the value from the same source the indexer recorded it from is the only fix that closes it rather than narrowing the window.

I also want to credit @chao-hsu-14 here: their independent confirmation on 0.10.8 — generation_matches true and coverage recording complete, yet every sampled path still reporting freshness: metadata_changed — is what turned this from a plausible diagnosis into a settled one. Two people arriving at the same place from different directions is the strongest evidence a bug report can carry.

Thank you both. Sorry it took so long to act on work that was ready.