abhigyanpatwari/GitNexus · warning
GitNexus [query:vector]: vector index query failed; using ex
Error message
GitNexus [query:vector]: vector index query failed; using exact scan fallback
What it means
The vector (ANN) index query in the MCP query tool's semantic path failed; bestChunks is reset to an empty Map and the code falls back to a brute-force exact scan. The diagnostic fires once per LocalBackend instance (warnedVectorUnsupported) to keep stderr quiet on hot paths. The fallback has its own ceiling: when the embedding count exceeds getExactScanLimit(), the exact scan returns [] rather than scanning.
Source
Thrown at gitnexus/src/mcp/local/local-backend.ts:3258
`;
const embResults = await executeQuery(repo.lbugPath, vectorQuery);
return embResults.map((row) => ({
nodeId: row.nodeId ?? row[0],
chunkIndex: row.chunkIndex ?? row[1] ?? 0,
startLine: row.startLine ?? row[2] ?? 0,
endLine: row.endLine ?? row[3] ?? 0,
distance: row.distance ?? row[4],
}));
});
} catch (err) {
bestChunks = new Map();
if (!this.warnedVectorUnsupported) {
// Rare diagnostic: surface why semantic search fell back to the
// exact scan. Emitted once per `LocalBackend` instance lifetime to
// avoid noisy stderr on hot semantic-search paths (DoD §2.8).
this.warnedVectorUnsupported = true;
logger.warn(
{ err },
'GitNexus [query:vector]: vector index query failed; using exact scan fallback',
);
}
}
if (bestChunks.size === 0) {
const embeddingCount = Number(tableCheck[0].cnt ?? tableCheck[0][0] ?? 0);
const exactLimit = getExactScanLimit();
if (embeddingCount > exactLimit) return [];
const rows = await executeQuery(
repo.lbugPath,
`
MATCH (e:${EMBEDDING_TABLE_NAME})
RETURN e.nodeId AS nodeId, e.chunkIndex AS chunkIndex,
e.startLine AS startLine, e.endLine AS endLine, e.embedding AS embedding
`,View on GitHub (pinned to aac7515d2a)
Solutions
- Re-run analyze with a current version so embeddings and the vector index are built.
- Check the single warn at first fallback — its err names the actual engine reason (extension vs corruption).
- If results come back empty on a large DB, suspect the exact-scan limit: rebuild embeddings so the ANN path works instead of relying on the capped fallback.
- Ensure the MCP server process loads the same LadybugDB build (with vector extension) as the CLI that indexed.
Defensive patterns
Strategy: fallback
Validate before calling
// Before semantic search at scale: check embedding count vs the exact-scan limit
const cnt = await countEmbeddings(repo.lbugPath);
if (cnt > getExactScanLimit()) {
await ensureVectorIndex(repo.lbugPath); // rebuild so ANN works; exact scan would return []
} Try / catch
try {
bestChunks = await vectorIndexQuery(queryVec, k);
} catch (err) {
bestChunks = new Map(); // exact-scan fallback path
warnOnce(err); // first failure only — avoid noisy hot-path stderr
if (embeddingCount > exactLimit) return []; // fallback ceiling: too big to brute-force
} Prevention
- Rebuild embeddings (analyze with a current version) so the ANN index exists.
- Watch for the once-per-instance warn at query time — it is the only visible clue of permanent fallback.
- Remember the exact-scan fallback silently returns [] above getExactScanLimit() — size accordingly.
When it happens
Trigger: A semantic query runs; the vector-index query over the EMBEDDING table throws — LadybugDB build without the vector extension, index missing on a DB from before embeddings, or a corrupted index. First occurrence warns with the underlying err; later occurrences are silent for that instance.
Common situations: DBs indexed before embedding support or with embeddings disabled; MCP processes with a LadybugDB lacking vector extensions; very large embedding tables where the exact-scan limit then empties results entirely.
Related errors
- [embed] Failed to delete stale embedding rows — aborting to
- deleteNodesForFile: ${EMBEDDING_TABLE_NAME} table does not e
- deleteNodesForFiles: ${EMBEDDING_TABLE_NAME} table does not
- GitNexus query failed (degraded)
- GitNexus: BM25/FTS search failed (FTS indexes may not exist)
AI-assisted analysis of abhigyanpatwari/GitNexus@aac7515d2a (2026-08-20).
Data as JSON: /api/errors/dda8f0f37f85e9f8.
Report an issue: GitHub.