Repository navigation
index_repository reports parse_partial_count: 0 after incremental/artifact reload despite persisted coverage gaps #1287
Description
Version
codebase-memory-mcp dev on Linux x86_64.
What happened
index_repository reports parse_partial_count: 0 after an incremental/no-change full request and after importing a persisted team artifact, even though the resulting persisted graph contains known parse-partial files.
The graph data and persisted coverage metadata are otherwise correct:
index_statusimmediately reportsparse_partial.count: 2query_graph(graph="missed")immediately returns the same twoparse_partialfilescheck_index_coveragereportsgeneration_matches: true- the same coverage survives daemon restart and reload
This means the response from index_repository can falsely make the current index look coverage-clean.
Reproduction
Using a repository with two stable parse-partial files and an existing persisted artifact:
codebase-memory-mcp cli --json index_repository \
'{"repo_path":"/path/to/repo","mode":"full","persistence":true}'
codebase-memory-mcp cli --json index_status \
'{"project":"project-name","verbose":true}'
codebase-memory-mcp cli --json query_graph \
'{"project":"project-name","graph":"missed","query":"MATCH (f:File) RETURN f.file_path, f.kind, f.detail ORDER BY f.file_path"}'Observed index_repository response:
{
"nodes": 12131,
"edges": 70812,
"skipped_count": 0,
"parse_partial_count": 0,
"status": "indexed"
}Immediate index_status result:
{
"parse_partial": {
"files": [
{
"path": "library/logging/live_plotter/web/dashboard_extras.html",
"error_ranges": "244-244"
},
{
"path": "run_benchmark.ps1",
"error_ranges": "..."
}
],
"count": 2,
"truncated": false
}
}Immediate missed-graph query:
library/logging/live_plotter/web/dashboard_extras.html parse_partial 244-244
run_benchmark.ps1 parse_partial ...
total: 2
I reproduced the same mismatch with an empty isolated CBM_CACHE_DIR, where index_repository imported .codebase-memory/graph.db.zst and produced the correct persisted graph. Its response still said parse_partial_count: 0, while a fresh CLI process loading that cache reported both partial files.
Expected behavior
After incremental reconciliation or artifact import, index_repository should report the current persisted coverage state, including pre-existing/imported parse-partial and skipped files.
If these fields are intentionally run-local rather than current-state totals, they should be named/documented accordingly and the response should also expose the authoritative persisted totals. The current tool description says the response reports files that were not fully indexed, so a zero is unsafe for agents deciding whether graph-only evidence is sufficient.
Scope
This appears to be a response-assembly/coverage-summary issue, not graph corruption:
- no stale or duplicate symbols were found
OVERRIDEedges survived incremental refresh, deletion, restart, and artifact reload- node and edge totals remained stable across reloads
- generation metadata remained matched
This follows up the coverage-signal work in #963.
It is separate from the cross-clone artifact identity problem in #885.
Activity
DeusData commentedon Jul 28, 2026
Thanks for distinguishing the live parse warning from persisted coverage state.
Current main builds parse_partial_count only from the current pipeline file-error array (src/mcp/mcp.c:6869-6908). An incremental no-op or artifact bootstrap has no reconstruction step that repopulates that array from stored coverage rows before composing the index response. That directly explains how the response can say zero while the persisted graph still contains coverage gaps.
I have routed this silent-status mismatch to 0.9.1-rc at priority/high. Thank you for checking both incremental and artifact reload paths.
cherryb16 commentedon Aug 13, 2026
Confirming this on a release build,
codebase-memory-mcp 0.10.3, macOS arm64 (Darwin 27.0.0) — the original report isdevon Linux x86_64, so this is not dev-build-specific.Same shape as described. Re-indexing an already-indexed repo with
--mode full:index_repository→parse_partial_count: 0check_index_coverage(same generation,generation_matches: true,recording_status: complete) → all files stillpartial, byte-identical error rangesindex_status→ agrees withcheck_index_coverage, 39 files partialThe practical impact worth flagging: this masks genuine parse gaps precisely when someone re-indexes to check whether a coverage problem was fixed. In my case it briefly looked like a
--mode fullre-index had resolved a SQL parsing issue; it had not —check_index_coverageshowed the identical ranges. Filed that underlying SQL/PL-pgSQL parsing gap separately as #1598.Suggestion, if useful: having
index_repositoryread back from the same persisted coverage metadata thatindex_statusandcheck_index_coverageuse — rather than reporting from the in-flight pass — would make the three surfaces agree by construction.DeusData commentedon Aug 18, 2026
Fixed on main by afebf00 (PR #1326, thanks @Enferlain): the index response now composes its skipped/parse-partial summaries from the persisted coverage set (with a per-run fallback if the store read fails), so incremental runs that don't revisit a flagged file no longer report the gaps as vanished.