Cannot repair FTS indexes: the index is…

Error message

Cannot repair FTS indexes: the index is mid-incremental-recovery (a previous analyze run did not complete cleanly). Run `gitnexus analyze` first — it recovers the index automatically — then retry `--repair-fts`.

What it means

Error "Cannot repair FTS indexes: the index is mid-incremental-recovery (a previous analyze run did not complete cleanly). Run `gitnexus analyze` first — it recovers the index automatically — then retry `--repair-fts`." thrown in abhigyanpatwari/GitNexus.

Solutions

Run `gitnexus analyze` (without `--repair-fts`): the run detects the mid-recovery state and completes the pending incremental writeback automatically.
After that run finishes cleanly, re-run `gitnexus analyze --repair-fts` to rebuild the FTS indexes.
If `analyze` repeatedly reports the dirty/recovery flag (incrementalInProgress stuck), remove the corrupt index directory and do a full `gitnexus analyze` (or `--force`) rebuild.

Defensive patterns

Strategy: try-catch

When it happens

Trigger: Thrown at gitnexus/src/core/run-analyze.ts:1132 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/37dd64b3350389b6. Report an issue: GitHub.

Appendix: source

Thrown at gitnexus/src/core/run-analyze.ts:1342

  if (options.repairFts) {
    if (!existingMeta) {
      throw new Error(
        'Cannot repair FTS indexes because this repository has not been analyzed yet. ' +
          'Run `gitnexus analyze` first to create the initial index, then retry `--repair-fts`.',
      );
    }
    if (shouldRefuseRepairFtsWhileDirty(existingMeta.incrementalInProgress)) {
      // #2409 / tri-review 4669518496 (R6): a non-FTS dirty flag means the
      // previous run died mid-writeback — the graph may be half-written and
      // its WAL possibly poisoned. This branch returns early, so the
      // dirty-recovery sidecar quarantine below would never run: repairing
      // FTS now would open the DB and replay that WAL pre-quarantine, and
      // even a survivable open would certify FTS over a half-written graph.
      // An FTS-phase flag with a successful checkpoint is different (KTD4):
      // the graph-boundary checkpoint already ran, so `--repair-fts` must
      // stay usable (R8). Missing/failed checkpoint is treated like a
      // half-written graph.
      throw new Error(
        'Cannot repair FTS indexes: the index is mid-incremental-recovery ' +
          '(a previous analyze run did not complete cleanly). ' +
          'Run `gitnexus analyze` first — it recovers the index automatically — ' +
          'then retry `--repair-fts`.',
      );
    }
    let lbugStat;
    try {
      lbugStat = await fs.lstat(lbugPath);
    } catch {
      throw new Error(
        `Cannot repair FTS indexes: graph store at ${lbugPath} is missing. ` +
          'Run `gitnexus analyze` (full) to rebuild from scratch.',
      );
    }
    if (!lbugStat.isFile()) {
      const foundType = lbugStat.isDirectory()
        ? 'a directory'

View on GitHub (pinned to ac9a4e9abd)