parsedfile-cache: could not reset durable chunk generation;

Error message

parsedfile-cache: could not reset durable chunk generation; continuing

What it means

With the durable parsed-file cache enabled, the parse phase stores each chunk's raw worker results on disk keyed by chunk hash. On a cache miss it calls prepareDurableParsedFileChunk(durableParsedFileDir, chunkHash) to reset that chunk's directory before workers write a fresh generation; if that reset throws (permissions, ENOSPC, stale lock, directory removed concurrently), the catch warns 'parsedfile-cache: could not reset durable chunk generation; continuing' and the analyze proceeds — the cache is an optimization, workers recreate the directory on write, and at worst the old generation lingers.

Source

Thrown at gitnexus/src/core/ingestion/pipeline-phases/parse-impl.ts:1081

            nodesCreated: graph.nodeCount,
          },
        });
        // The durable gate already snapshotted warm `.v8` shards into the
        // run-scoped store for scope resolution.
        await applyChunkResults(chunkWorkerData, chunkIdx, chunkFiles, chunkStartMs);
      } else {
        // Cache miss: dispatch to workers, capture the raw results, store
        // them under the chunk hash for the next run.
        chunkCacheMisses++;
        reparsedFileCount += chunkFiles.length;
        if (durableParsedFileDir !== undefined && chunkHash !== null) {
          try {
            await prepareDurableParsedFileChunk(durableParsedFileDir, chunkHash);
          } catch (err) {
            // The durable store is an optimization — degrade like the restore
            // path does instead of failing the analyze. Workers recreate the
            // directory on write, so at worst the old generation lingers.
            logger.warn(
              { err, chunkHash: chunkHash.slice(0, 8) },
              'parsedfile-cache: could not reset durable chunk generation; continuing',
            );
          }
        }
        const progressForChunk = (current: number, _total: number, filePath: string) => {
          const globalCurrent = filesParsedSoFar + current;
          // Parse phase covers 20-70 (M2). Deferred extraction handles 70-95.
          const parsingProgress = 20 + (globalCurrent / totalParseable) * 50;
          onProgress({
            phase: 'parsing',
            percent: Math.round(parsingProgress),
            message: `Parsing chunk ${chunkIdx + 1}/${numChunks}...`,
            detail: filePath,
            stats: {
              filesProcessed: globalCurrent,
              totalFiles: totalParseable,
              nodesCreated: graph.nodeCount,

View on GitHub (pinned to 52924ef12c)

Solutions

Check the logged { err } — EACCES/EPERM points to permissions, ENOSPC to disk space
chown/chmod the durable cache directory so the indexing user can write it
Free disk space or move the cache to a volume with headroom
Delete the stale chunk generation (the warn includes the chunkHash prefix) or clear the cache once
Otherwise ignore it — analyze results are unaffected; only cache freshness for this run degrades

Example fix

# before: cache dir owned by root, analyze runs as ci-user -> EACCES warn
chown -R root:root <durable-parsedfile-dir>  # wrong owner

# after: hand the cache to the indexing user, then re-run
chown -R ci-user:ci-user <durable-parsedfile-dir> && npx gitnexus analyze

Defensive patterns

Strategy: fallback

Validate before calling

// preflight before analyze: writable cache dir with free space
import fs from 'node:fs';
fs.accessSync(durableParsedFileDir, fs.constants.W_OK); // throws EACCES early, with a clear cause
assertFreeSpace(durableParsedFileDir, 512 * 1024 * 1024);

Try / catch

try {
  await prepareDurableParsedFileChunk(durableParsedFileDir, chunkHash);
} catch (err) {
  logger.warn({ err, chunkHash: chunkHash.slice(0, 8) }, 'parsedfile-cache: could not reset durable chunk generation; continuing');
}

Prevention

Own the durable cache directory with the same user that runs analyze
Do not mount the cache volume read-only in CI
Monitor disk space on the cache drive (ENOSPC is the other common cause)
Treat this warn as cache-only: analyze correctness is unaffected

When it happens

Trigger: The durable cache directory being unwritable (EACCES/EPERM, read-only mount), the disk being full (ENOSPC), a stale lock/ownership left by a previous run under another user, or the cache being wiped while the analyze runs.

Common situations: CI pipelines mounting a cache volume read-only or root-owned; cache dir created by root then reused by a non-root user; disk pressure on the cache drive; cache cleaned concurrently by another job.

Related errors

AI-assisted analysis of abhigyanpatwari/GitNexus@52924ef12c (2026-08-20). Data as JSON: /api/errors/73fc754baf33ed23. Report an issue: GitHub.