abhigyanpatwari/GitNexus · error
FTS repair failed - missing indexes after rebuild
Error message
FTS repair failed - missing indexes after rebuild: ${missing.join(', ')}.${reasons} Run `gitnexus analyze --force` to perform a full graph+FTS rebuild; if that also fails, verify FTS extension availability via `gitnexus doctor`. What it means
Error "FTS repair failed - missing indexes after rebuild: ${missing.join(', ')}.${reasons} Run `gitnexus analyze --force` to perform a full graph+FTS rebuild; if that also fails, verify FTS extension availability via `gitnexus doctor`." thrown in abhigyanpatwari/GitNexus.
Solutions
- Run `gitnexus analyze --force` to perform a full graph+FTS rebuild from scratch, replacing the partially repaired indexes.
- Run `gitnexus doctor` to verify FTS extension availability; if the extension is missing, install/load the FTS support required by the storage backend before rebuilding.
- Review the per-index `reasons` in the message: indexes absent from the missing list were already repaired; focus on the named ones and any reported cause (e.g. table creation failure or extension unavailability).
- If full rebuild also fails, check disk space and database file integrity, then recreate the index directory and re-run `gitnexus analyze`.
Defensive patterns
Strategy: try-catch
When it happens
Trigger: Thrown at gitnexus/src/core/run-analyze.ts:1225 when the library encounters an invalid state.
Common situations: See trigger scenarios.
AI-assisted analysis of abhigyanpatwari/GitNexus@ac9a4e9abd (2026-09-15).
Data as JSON: /api/errors/b973c68114516774.
Report an issue: GitHub.
Appendix: source
Thrown at gitnexus/src/core/run-analyze.ts:1479
? (table, indexName) => log(`FTS: creating ${table}.${indexName}`)
: undefined,
onIndexReady: options.verbose
? (table, indexName) => log(`FTS: ready ${table}.${indexName}`)
: undefined,
});
const missing = await verifySearchFTSIndexes(executeQuery, ftsIndexes);
if (missing.length > 0) {
// #2889: name WHY each index is missing when the build itself said so.
// Repair now rebuilds every table it can before reporting, so the tables
// absent from this list were genuinely repaired even on a failed run —
// previously the first failure aborted the sweep and the message could
// only ever list "missing", never a reason. Same sentence the analyze
// degrade path prints, so one failure does not read two ways.
const reasons =
repairFailures.length > 0
? ` ${summarizeFtsIndexBuildFailures(repairFailures, ftsIndexes)}.`
: '';
throw new Error(
`FTS repair failed - missing indexes after rebuild: ${missing.join(', ')}.${reasons} ` +
'Run `gitnexus analyze --force` to perform a full graph+FTS rebuild; ' +
'if that also fails, verify FTS extension availability via `gitnexus doctor`.',
);
}
await ensureGitNexusIgnored(repoPath, storagePath);
// #2767: stamp ONLY capabilities.fts so a long-lived MCP session's
// ensureInitialized() has an explicit, correctly-scoped signal that FTS
// changed — indexedAt/lastCommit/runnerIdentity/stats are copied through
// untouched (see the "must not claim a new analyzer identity" comment
// below). capabilities is forensic/no-programmatic-readers-until-now, so
// graph/vectorSearch are backfilled with conservative, honest defaults
// when a legacy meta.json predates this field entirely — repair-fts
// never touched them and cannot claim a capability it did not verify.
// Best-effort: a write failure must not turn an already-successful FTS
// rebuild into a reported repair failure.
try {
// Re-read the on-disk meta immediately before writing, rather thanView on GitHub (pinned to ac9a4e9abd)