Cannot park after an in-place FTS abort )` : ''}. The…

Error message

Cannot park ${path.basename(failedPath)} after an in-place FTS abort${detail ? ` (${detail})` : ''}. The database was not opened. Run `gitnexus clean --lbug-sidecars` after stopping any GitNexus MCP or serve process, then retry `gitnexus analyze` or `gitnexus analyze --repair-fts`.

What it means

runFullAnalysisInner, before running --repair-fts, parks leftover WAL/shadow sidecars from a previous in-place FTS abort via quarantineSidecarsForDirtyRecovery; if any park/remove fails it throws the ftsCrashParkFailureMessage error naming the first failed path. The database was not opened, so no corruption occurred; manual sidecar cleanup is required before repair can proceed.

Solutions

Stop any GitNexus MCP or serve process.
Run `gitnexus clean --lbug-sidecars` to clear the leftover sidecars.
Retry `gitnexus analyze` or `gitnexus analyze --repair-fts`.
Verify write permissions on .gitnexus/ and free disk space if the failure persists.

Defensive patterns

Strategy: try-catch

Try / catch

try {
  await runAnalyze({ repairFts: true });
} catch (err) {
  if (err instanceof Error && err.message.includes('Cannot park')) {
    console.error('Stop MCP/serve processes, then `gitnexus clean --lbug-sidecars`, then retry repair.');
  } else throw err;
}

Prevention

Ensure no other GitNexus process holds the database before --repair-fts.
Verify write permissions and disk space in .gitnexus/ before repair.
Prevent analyze crashes mid-FTS-checkpoint (clean shutdowns only).

When it happens

Trigger: Running `gitnexus analyze --repair-fts` when a prior in-place FTS checkpoint crashed and the leftover WAL/shadow sidecars cannot be parked (locked files, permissions, disk issues).

Common situations: Another GitNexus MCP/serve process still holding the sidecar files; antivirus locking .wal/.shadow files; read-only or full disk; permission changes after moving the repo.

Related errors

AI-assisted analysis of abhigyanpatwari/GitNexus@ac9a4e9abd (2026-09-15). Data as JSON: /api/errors/6323df6abebcb075. Report an issue: GitHub.

Appendix: source

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

                  ? 'a FIFO'
                  : 'not a regular file';
      throw new Error(
        `Cannot repair FTS indexes: graph store at ${lbugPath} is ${foundType} (expected a file). ` +
          'Run `gitnexus analyze` (full) to rebuild from scratch.',
      );
    }
    await ensureWritableStorage();
    // P1 R8: park a poisoned live WAL before opening. Staging never parks —
    // the live index next to an unpublished staging file must replay its WAL.
    const repairDirty = existingMeta.incrementalInProgress;
    if (shouldRefuseFtsCrashWal(repairDirty, existingMeta.capabilities?.fts)) {
      const {
        moved: repairParked,
        removed: repairRemoved,
        failed: repairParkFailed,
      } = await quarantineSidecarsForDirtyRecovery(lbugPath, (message) => log(`   ${message}`));
      if (repairParkFailed.length > 0) {
        throw new Error(ftsCrashParkFailureMessage(repairParkFailed[0]!));
      }
      if (repairParked.length + repairRemoved.length > 0) {
        log('Parked leftover WAL/shadow from the previous in-place FTS abort before --repair-fts.');
      }
    }
    try {
      await initAnalysisLbug(lbugPath);
      // Gate on FTS availability BEFORE touching any index. createSearchFTSIndexes
      // now DROPs each index before recreating it (so schema changes reach existing
      // DBs); if the extension were unavailable, the drops would run and leave the
      // DB index-less, only failing at the create step. Fail loudly first — mirrors
      // the analyze path's `if (ftsAvailable)` gate below — so an unavailable
      // extension never destroys the existing indexes.
      const repairFtsAvailable = await loadFTSExtension(undefined, {
        policy: resolveAnalyzeInstallPolicy(),
      });
      if (!repairFtsAvailable) {
        // Surface the load-side reason (#2374): "not pre-installed" was wrong

View on GitHub (pinned to ac9a4e9abd)