Incremental importer BFS: dropped chunk ${chunkIndex} (${bat

Error message

Incremental importer BFS: dropped chunk ${chunkIndex} (${batch.length} target path(s)) — importer expansion degrades for this run; affected importers may keep stale edges until the next full rebuild.

What it means

The incremental importer BFS expands 'who imports the changed files' in batched queries; one chunk's query failed, so every importer those target paths would have surfaced is dropped from the expansion set. Consequence stated in the message: affected importers can keep stale edges until the next full rebuild. Loud by design (the old bare catch{} left no trace), and it notifies options.onChunkFailure(chunkIndex, batch.length, err).

Source

Thrown at gitnexus/src/core/lbug/lbug-adapter.ts:2719

      RETURN DISTINCT a.filePath AS importer
    `;
    await withConnLock(async () => {
      let queryResult: lbug.QueryResult | lbug.QueryResult[] | undefined;
      try {
        queryResult = await c.query(cypher);
        const result = Array.isArray(queryResult) ? queryResult[0] : queryResult;
        const rows = await result.getAll();
        for (const row of rows) {
          const v = (row as { importer?: unknown }).importer;
          if (typeof v === 'string' && v.length > 0) importers.add(v);
        }
      } catch (err) {
        // Degrade-don't-fail, mirroring queryImporters — but LOUDLY
        // (tri-review 4669518496 P2-5): a dropped chunk means every importer
        // it would have surfaced keeps possibly-stale edges this run, and the
        // old bare `catch {}` left no trace of that anywhere. pino idiom:
        // `err` key — `error` serializes to `{}`.
        logger.warn(
          { err },
          `Incremental importer BFS: dropped chunk ${chunkIndex} (${batch.length} target path(s)) — ` +
            'importer expansion degrades for this run; affected importers may keep stale edges until the next full rebuild.',
        );
        options.onChunkFailure?.(chunkIndex, batch.length, err);
      } finally {
        if (queryResult) await closeQueryResults(queryResult);
      }
    });
  }
  // Cypher without ORDER BY is unordered — sort so downstream chunking and
  // logs are stable run-to-run (matches diffFileHashes' sorted outputs).
  return [...importers].sort();
};

/**
 * Drop every Community and Process node (and their MEMBER_OF /
 * STEP_IN_PROCESS edges via DETACH DELETE). Used at the start of an

View on GitHub (pinned to aac7515d2a)

Solutions

Re-run the incremental analyze — the next run re-queries all chunks and usually completes the expansion.
Wire/surface options.onChunkFailure in your orchestration to count degraded runs and trigger repair.
Stop concurrent serve/MCP traffic against the DB during incremental updates to remove lock contention.
If stale edges are suspected, schedule a full rebuild (`analyze --force`) to reconcile.

Example fix

// before: chunk failure invisible, stale edges linger unexplained
await deleteNodesForFiles(...);

// after: observe degraded chunks and repair
await deleteNodesForFiles(targets, {
  onChunkFailure: (chunkIndex, count, err) => {
    metrics.incr('importer_bfs_dropped');
    log.warn({ chunkIndex, count, err }, 'scheduling full rebuild');
    scheduleFullRebuild();
  },
});

Defensive patterns

Strategy: fallback

Try / catch

// Degrade-don't-fail per chunk; observe and repair
const importers = await collectImporters(dbPath, targets, {
  onChunkFailure: (chunkIndex, count, err) => {
    degradedChunks.push({ chunkIndex, count, err: String(err) });
  },
});
if (degradedChunks.length > 0) queueFullRebuild(); // stale edges until then

Prevention

Always wire onChunkFailure in orchestration code — it is the structured signal behind the warn.
Schedule a periodic full rebuild as a safety net for degraded incremental runs.
Avoid concurrent heavy reads during incremental analyze to prevent chunk query failures.

When it happens

Trigger: collectImportersForFiles-style BFS runs during incremental analyze; a per-chunk Cypher query throws (lock timeout, transient I/O, connection blip). The catch degrades-don't-fails for that chunk, logs with pino's `err` key (not `error`, which serializes to {}), and moves to the next chunk.

Common situations: Incremental runs racing a long serve query holding locks; flaky network filesystems under the DB; memory pressure causing native query faults; very large batches amplifying query timeouts.

Related errors

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