Repository navigation
index_status(verbose) reports the live repo head_sha, not the indexed generation — misleading freshness signal #1559
Description
Environment: v0.10.2, Windows 11, daemon mode, --mode full.
Symptom
index_status(verbose=true) returns git.head_sha (and branch info) read from the live repository, not from the indexed generation. Sequence observed:
- Index built at generation T0 (HEAD =
dbbec50…). - New commit
34d6c6f…lands; the watcher has not yet reindexed — node count and graph content are still T0, andcheck_index_coveragestill reportsmetadata.generation= T0. index_status(verbose=true)already reportshead_sha=34d6c6f….
A freshness poll keyed on head_sha therefore declares "index up to date" while the graph is stale. Also mildly surprising: non-verbose index_status omits the git block entirely, so the same poll silently compares against an empty field forever.
Suggestion
Expose the indexed generation's commit alongside the live one — e.g. git.head_sha (live) + git.indexed_sha (what the graph was built from; coverage already exposes metadata.generation as a timestamp). That gives clients a truthful staleness signal: indexed_sha != head_sha ⇒ stale.
Activity
DeusData commentedon Aug 12, 2026
Thank you @PsyTech-Rob. Confirmed on current
main: verboseindex_statuscallsadd_git_context_json()against the liveroot_pathat request time, while the published generation does not persist the checkout identity it indexed. The reportedhead_shacan therefore look current even when the graph represents an older checkout.#1561 proposes the corresponding persisted-generation and bounded live-checkout evidence. This is routed priority/high; because it already has a linked implementation PR, it intentionally skips separate epic grouping.
DeusData commentedon Sep 26, 2026
Thank you, @PsyTech-Rob! The freshness poll you describe is exactly the client pattern that turns a live
head_shainto a false "up to date". This is covered by #1561 from @tmonestudio. That PR records the checkout the graph was actually built from at publication time, and reports anindex_status.freshnessobject: a verdict of current, stale or unknown, together with the reasons and a recommended action. That's the "indexed vs live" signal you asked for, and it explains why. I'm keeping this issue linked to #1561 and will close it when that lands.