What causes "Could not verify persisted embedding count." in abhigyanpatwari/GitNexus?

Rerun `gitnexus embeddings sync` — the unverified-count checkpoint forces a recount and the count usually verifies on the retry.

abhigyanpatwari/GitNexus · error

Could not verify persisted embedding count.

Error message

Could not verify persisted embedding count.

What it means

Thrown by embeddingsSyncCommand after the embedding pipeline finishes but countEmbeddings() returns undefined, meaning the number of persisted embeddings in the database could not be determined. Before throwing, the command deliberately persists an unverified-count (or partial) checkpoint so the next run forces a recount instead of trusting a possibly-wrong count. This is a conservative integrity guard, not a data-loss signal.

Solutions

Rerun `gitnexus embeddings sync` — the unverified-count checkpoint forces a recount and the count usually verifies on the retry.
Check the LadybugDB index files are readable and not locked by another process (e.g. a concurrent `gitnexus serve`).
If it persists, verify the index with the doctor command / reopen the repo to rule out database corruption.
Inspect logs for the countEmbeddings() failure right before the throw to identify the underlying query error.

Defensive patterns

Strategy: retry

Try / catch

try {
  await embeddingsSyncCommand(...);
} catch (err) {
  if (err.message === 'Could not verify persisted embedding count.') {
    // safe to retry: unverified-count checkpoint forces a recount next run
    await embeddingsSyncCommand(...);
  }
}

Prevention

Avoid running `gitnexus serve` or other processes holding the LadybugDB lock during sync
Let the sync finish before killing the process — the verification happens at the end
Rerun sync after any interruption; the checkpoint design makes the retry a recount

When it happens

Trigger: Calling `gitnexus embeddings sync` and having countEmbeddings() return undefined after runEmbeddingPipeline completes — typically because the LadybugDB count query failed, the connection was interrupted mid-count, or the database was closed/unavailable at verification time.

Common situations: Flaky embedded-database state after long syncs; containerized runs where the LadybugDB file lock is contended; a sync interrupted during the final verification step.

Understand the failure class

Background: EmptyResultError / "no results found": when an API or scraper succeeds but returns zero rows — this error's family across 9 libraries.

Related errors

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

Appendix: source

Thrown at gitnexus/src/cli/embeddings-sync.ts:216

          },
        },
      );

      const embeddings = await countEmbeddings();
      if (embeddings === undefined) {
        // Keep last-known stats.embeddings. An interrupted window marker would
        // fail the identity gate on the next run even though this run finished;
        // unverified-count is the recovery kind that forces a recount (#2790).
        await persistMeta(() => ({
          embeddingCheckpoint: result.failedNodeIds.length
            ? mintPartialCheckpoint(identity, result, resumedFrom)
            : mintUnverifiedCountCheckpoint(identity, {
                nodesProcessed: result.nodesProcessed,
                totalNodes: result.nodesProcessed,
                chunksProcessed: result.chunksProcessed,
              }),
        }));
        throw new Error('Could not verify persisted embedding count.');
      }
      await persistMeta((latest) => ({
        stats: { ...latest.stats, embeddings },
        embeddingCheckpoint: result.failedNodeIds.length
          ? mintPartialCheckpoint(identity, result, resumedFrom)
          : undefined,
      }));
      cliInfo(`Embeddings ready: ${embeddings}`);
    } finally {
      await closeLbug().catch(() => {});
      await reapEmbeddingSidecarSafely();
    }
  } finally {
    lock.release();
  }
};

View on GitHub (pinned to ac9a4e9abd)