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

  1. Re-run analyze with a current version so embeddings and the vector index are built.
  2. Check the single warn at first fallback — its err names the actual engine reason (extension vs corruption).
  3. 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.
  4. 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

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


AI-assisted analysis of abhigyanpatwari/GitNexus@aac7515d2a (2026-08-20). Data as JSON: /api/errors/dda8f0f37f85e9f8. Report an issue: GitHub.