Branch.head_sha stale after re-indexing an existing project (freezes at creation-time HEAD)

[HorusScale]

Summary

Branch.head_sha in the graph does not update when re-indexing an already-existing project. It stays frozen at whatever commit was HEAD when the project was first created, even though the graph content itself (nodes/edges) updates correctly on re-index.

Environment

• cbm v0.9.0, linux-amd64 release, SHA-256 verified against checksums.txt
• Invoked directly via cli (no MCP server auto-install), isolated CBM_CACHE_DIR/CBM_ALLOWED_ROOT against a throwaway git repo

Repro (~5 commands)

1. Fresh index at commit A:
   cli index_repository --repo-path <repo> --name smoketest
   → MATCH (b:Branch) RETURN b.head_sha = A. Correct.

2. Advance HEAD to commit B (real commit, e.g. adding a function). Re-index the same project (default mode):
   cli index_repository --repo-path <repo> --name smoketest
   → graph content updates correctly (node/edge counts increase, new function present in the graph).
   → Branch.head_sha still reads A — unchanged.

3. Advance HEAD to commit C. Re-index explicitly with --mode full:
   → graph content updates again correctly.
   → Branch.head_sha now reads B — one commit behind the re-index that caused it, not C.

4. Control: delete_project then fresh index_repository (no prior project) at current HEAD:
   → Branch.head_sha correctly matches current HEAD immediately.

So the bug is specific to re-indexing an existing project — both default and --mode full — not to indexing itself.

Why this matters

Branch.head_sha (and index_status, which we separately confirmed reads live git HEAD rather than indexed-state — always "fresh," not useful either) are the two natural surfaces for a caller to answer "is the index actually caught up with the repo?" Neither gives a trustworthy answer in the normal long-lived-project + incremental-watcher-reindex scenario. A caller trusting Branch.head_sha as a freshness signal would see staleness silently understated forever after the first index, even while the watcher is correctly doing its job content-wise.

Suggested area to look

Whatever code path updates the Branch node's head_sha property likely only runs on project creation, not on the re-index/update path that touches node/edge content.

[TheDarkniteFalls]

I traced this on current main (5e7d3eb): the full structure pass upserts the Branch node from the captured Git context, but both successful incremental paths bypass that update. The changed-file path refreshes affected graph content only, while the no-change path returns without touching the database.

I can take a focused, test-first fix, subject to one contract check:

• add a self-contained temporary-Git regression covering A -> B with a tracked source change and B -> C with an empty commit;
• refresh the existing Branch metadata on every successful incremental indexing invocation, including runs whose indexed file hashes do not change;
• preserve the Branch node identity and edges, with no MCP schema or index_status changes.

Should Branch.head_sha mean “HEAD captured at the start of the successful indexing invocation,” matching the current full-index model, or should indexing detect a mid-run HEAD change and refuse/retry so the value is bound to one immutable repository state?

I would validate the change with the focused pipeline tests, full sanitizer test suite, lint/security gates, and a DCO-signed commit. I use AI-assisted tooling under human review and would disclose that in the PR.

[DeusData]

Thanks for tracing this to the incremental paths. The contract should remain consistent with a full index: Branch.head_sha means the HEAD captured at the start of the successful indexing invocation. Both changed-file and no-change incremental success must update the existing Branch node. Detecting or retrying when HEAD moves during an active run is a stronger snapshot-consistency feature and should be handled separately, not folded into this fix. This is now a high-priority 0.9.1-rc correctness bug under #391.

[TheDarkniteFalls]

Thanks—that resolves the contract. I’ll keep the fix narrowly scoped to refreshing the existing Branch metadata on changed-file and no-change incremental success, with the temporary-Git regression test and no schema, index_status, or mid-run snapshot changes.

I noticed #1245 also substantially changes incremental indexing and touches the same pipeline. Would this still be useful as a separate focused 0.9.1-rc PR, or would you prefer it coordinated with or held pending that review?