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

  1. Run `gitnexus analyze --force` to perform a full graph+FTS rebuild from scratch, replacing the partially repaired indexes.
  2. 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.
  3. 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).
  4. 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 than

View on GitHub (pinned to ac9a4e9abd)