Background/incremental sync never updates snapshot manager stats (get_indexing_status stays frozen at last full index)

Package

@zilliz/claude-context-mcp v0.1.14 (bundles @zilliz/claude-context-core v0.1.14)

Summary

SyncManager.handleSyncIndex() (in packages/mcp/src/sync.ts, compiled to dist/sync.js) correctly calls context.reindexByChange() on every periodic/initial/trigger-based sync, which does perform real incremental work (deletes stale chunks, re-embeds added/modified files into the vector DB). However, it never calls SnapshotManager.setCodebaseIndexed() afterward.

setCodebaseIndexed() is the only method that writes indexedFiles, totalChunks, and lastUpdated into ~/.context/mcp-codebase-snapshot.json (the file get_indexing_status reads). Searching the whole dist/ tree confirms setCodebaseIndexed( is called exclusively from the manual/full index_codebase code paths in handlers.js (5 call sites), never from sync.js.

Net effect: get_indexing_status permanently reports the timestamp/counts of the last full/manual index, no matter how many background sync cycles run afterward or how much real content they update. Users have no reliable way to tell, from the tool output, whether their index is actually current.

Evidence

• Grepped dist/sync.js: only calls on this.snapshotManager are getIndexedCodebases() and getCodebaseInfo() — no setter call after reindexByChange().
• Grepped dist/*.js for setCodebaseIndexed(: only appears in handlers.js (full-index / background-index / cloud-index / legacy-heal paths) and in the two test files.
• Confirmed the incremental path does work at the data layer: the per-codebase Merkle snapshot at ~/.context/merkle/<md5(path)>.json had its mtime updated mid-session, well after the last full index, while the long-lived MCP server process (>4h uptime, no restart) kept running — consistent with checkForChanges() detecting real diffs and reindexByChange() processing them.
• Meanwhile the codebase's entry in ~/.context/mcp-codebase-snapshot.json (lastUpdated) stayed frozen at the last manual index_codebase call, 2+ weeks and dozens of scheduled sync cycles later.
• Could not directly observe the periodic tick's own console output in this environment's MCP log capture (it appears to snapshot stderr once at connection time only), but the file-level evidence above is independent of that and conclusive on its own.

Suggested fix

After a successful context.reindexByChange() call in handleSyncIndex() that reports any changes (added/removed/modified > 0), refresh the snapshot manager stats, e.g. using the same getCollectionRowCount()-for-both-fields convention already used by the legacy self-heal logic in handlers.js:

if (stats.added > 0 || stats.removed > 0 || stats.modified > 0) {
    const collectionName = this.context.getCollectionName(codebasePath);
    const rowCount = await this.context.getVectorDatabase().getCollectionRowCount(collectionName);
    if (rowCount >= 0) {
        this.snapshotManager.setCodebaseIndexed(codebasePath, {
            indexedFiles: rowCount,
            totalChunks: rowCount,
            status: 'completed',
        });
        this.snapshotManager.saveCodebaseSnapshot();
    }
}

I've applied this exact patch locally (to the compiled dist/sync.js) and it passes node --check. Happy to open a PR against the TypeScript source if useful — let me know which file under packages/mcp/src/ currently maps to dist/sync.js in the version you'd like it against, since my install only has the compiled output.

Environment

• @zilliz/claude-context-mcp: 0.1.14
• Node: v24.10.0
• Vector DB: Milvus (self-hosted, 127.0.0.1:19530)
• Embedding provider: Ollama