abhigyanpatwari/GitNexus · warning

[embed] could not count persisted embeddings; leaving stats.

Error message

[embed] could not count persisted embeddings; leaving stats.embeddings untouched

What it means

After persisting embeddings, the server counts persisted rows via measurePersistedEmbeddingCount. The count is a tri-state; when it returns kind 'unknown' (the counting query itself failed), this warning fires and stats.embeddings is deliberately left untouched rather than set to 0: unknown is not 0, and only the fold in core/embedding-count.ts decides what to carry forward. The embeddings themselves were persisted; only the statistic is in doubt.

Source

Thrown at gitnexus/src/server/api.ts:1797

                      embeddingIdentity,
                      checkpoint,
                      pendingNodeIds,
                    ),
                  },
                  embeddings,
                );
                await saveMeta(entry.storagePath, embeddingMeta);
              };
              /**
               * Count the persisted rows, or report the answer never arrived.
               * The TRI-STATE is carried to the fold rather than collapsed here:
               * `unknown` is not 0, and only the fold knows what to carry
               * forward instead (core/embedding-count.ts).
               */
              const countPersistedEmbeddings = async (): Promise<PersistedEmbeddingCount> => {
                const counted = await measurePersistedEmbeddingCount(executeQuery);
                if (counted.kind === 'unknown') {
                  logger.warn(
                    { reason: counted.reason },
                    '[embed] could not count persisted embeddings; leaving stats.embeddings untouched',
                  );
                }
                return counted;
              };
              // Fetch existing content hashes for incremental embedding.
              // Delegated to lbug-adapter which owns the DB query logic and legacy-fallback handling.
              const { fetchExistingEmbeddingHashes } = await import('../core/lbug/lbug-adapter.js');
              const existingEmbeddings = await fetchExistingEmbeddingHashes(executeQuery);
              if (existingEmbeddings && existingEmbeddings.size > 0) {
                console.log(
                  `[embed] ${existingEmbeddings.size} nodes already embedded — incremental run with content-hash comparison`,
                );
              }
              const pipelineResult = await runEmbeddingPipeline(
                executeQuery,
                executeWithReusedStatement,

View on GitHub (pinned to aac7515d2a)

Solutions

1. No data was lost: the embeddings persisted, only the count is stale and carried forward by the fold
2. Re-run the embed step once the DB is uncontended to refresh the count
3. Stop overlapping schedules so embed and analyze do not run against the same storage concurrently
4. If it recurs, inspect the reason field in the warning to separate lock contention from real I/O failure

const counted = await measurePersistedEmbeddingCount(executeQuery);
// never treat unknown as 0 — carry the previous stat forward instead
stats.embeddings = counted.kind === 'unknown'
  ? previousStats.embeddings
  : counted.value;

type PersistedEmbeddingCount =
  | { kind: 'count'; value: number }
  | { kind: 'unknown'; reason: string };

function isUnknownCount(
  c: PersistedEmbeddingCount,
): c is { kind: 'unknown'; reason: string } {
  return c.kind === 'unknown';
}

When it happens

Trigger: An embed/analyze run with embeddings enabled where the count query against the LadybugDB store fails: transient query error, DB file lock held by a concurrent process, or a degraded read. The warning carries the failure reason from the tri-state result.

Common situations: Concurrent GitNexus processes contending on the LadybugDB file (its file locking is known to be finicky in containers); transient I/O errors; the displayed embedding count then reflects the previous value instead of the rows just written.

Understand the failure class

Background: Database query failed: Internal Server Error 500s wrapping SQL, Prisma, and connection failures — what to check first — this error's family across 16 libraries.

Related errors

• [embed] Failed to delete stale embedding rows — aborting to
• Bridge query prepare failed: ${errMsg}
• deleteNodesForFile: ${EMBEDDING_TABLE_NAME} table does not e
• deleteNodesForFiles: ${EMBEDDING_TABLE_NAME} table does not
• GitNexus [query:vector]: vector index query failed; using ex

AI-assisted analysis of abhigyanpatwari/GitNexus@aac7515d2a (2026-08-20). Data as JSON: /api/errors/94f537729e675d82. Report an issue: GitHub.