abhigyanpatwari/GitNexus · error · Error

Cannot repair FTS indexes: graph store at ${lbugPath} is mis

Error message

Cannot repair FTS indexes: graph store at ${lbugPath} is missing. Run `gitnexus analyze` (full) to rebuild from scratch.

What it means

Thrown during the `--repair-fts` path when `fs.lstat(lbugPath)` rejects — the LadybugDB graph store file does not exist on disk. FTS indexes live inside the same database file as the graph, so there is nothing to attach FTS indexes to without a graph store. The remedy is to run a full `gitnexus analyze` which creates the graph store from scratch.

Source

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

    if (existingMeta.incrementalInProgress) {
      // #2409 / tri-review 4669518496 (R6): a 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.
      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'
        : lbugStat.isSymbolicLink()
          ? 'a symbolic link'
          : lbugStat.isSocket()
            ? 'a socket'
            : lbugStat.isBlockDevice()
              ? 'a block device'
              : lbugStat.isCharacterDevice()
                ? 'a character device'
                : lbugStat.isFIFO()
                  ? 'a FIFO'
                  : 'not a regular file';

View on GitHub (pinned to d540b00184)

Solutions

Run `gitnexus analyze` (full) to create the graph store from scratch.
Once the full analyze completes and `gitnexus status` shows the graph, retry `--repair-fts` if keyword search is still degraded.
If the issue persists, check that `.gitnexus/` is writable and not on a filesystem that silently drops files.

Example fix

// before
gitnexus analyze --repair-fts  // fails: graph store missing
// after
gitnexus analyze               // creates the graph store
gitnexus analyze --repair-fts  // FTS repair now has a DB to work with

Defensive patterns

Strategy: validation

Validate before calling

// Before repair-fts, verify the graph store file exists:
import { access } from 'fs/promises';
try {
  await access(lbugPath);
} catch {
  console.error(`Graph store not found at ${lbugPath}. Run 'gitnexus analyze' first.`);
  process.exit(1);
}

Type guard

import { pathExists } from 'fs-extra';
const graphStoreExists = async (p: string): Promise<boolean> => {
  try { await access(p); return true; } catch { return false; }
};

Try / catch

try {
  await runAnalyze({ ...options, repairFts: true });
} catch (err) {
  if (err instanceof Error && err.message.includes('graph store at') && err.message.includes('is missing')) {
    console.error('Run `gitnexus analyze` (full) to create the graph store first.');
  }
  throw err;
}

Prevention

Run `gitnexus status` before `--repair-fts` to confirm the graph store exists and is indexed.
Never manually delete `.gitnexus/` store files without re-running `gitnexus analyze` afterward.

When it happens

Trigger: The FTS-only repair path reaches the `fs.lstat(lbugPath)` call and it throws ENOENT (or any lstat error). Occurs when the repository was never fully analyzed, the `.gitnexus` store directory was manually deleted, or a previous `--force` rebuild failed before creating the DB.

Common situations: An operator deletes `.gitnexus/` to save space or recover from corruption and then tries `--repair-fts` without re-indexing first; or a fresh clone where only a partial/meta write happened but the DB file itself was never created.

Related errors

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