parsedfile-store: dropped malformed/over-bound sites at load

Error message

parsedfile-store: dropped malformed/over-bound sites at load; files retained without those facts

What it means

The durable ParsedFile store is treated as an untrusted serialization boundary, and sanitation is per-site rather than per-file: a malformed or over-bound fact drops only itself while the file is retained. This warning reports that sites (and call chains) were dropped at warm-load, so those files lack those facts this run — and because retained files never re-extract, a drop that recurs on every warm load must be observable rather than silent (#2522 review).

Source

Thrown at gitnexus/src/storage/parsedfile-store.ts:311

        const flow = sanitizeCallableFlowSites(pf.callableFlowSites);
        if (flow === undefined) {
          rejectedFiles++;
          continue;
        }
        const chains = sanitizeReceiverChains(pf.referenceSites);
        if (chains === undefined) {
          rejectedFiles++;
          continue;
        }
        if (flow.dropped === 0 && chains.dropped === 0) {
          out.set(pf.filePath, pf);
        } else {
          droppedSites += flow.dropped;
          droppedChains += chains.dropped;
          filesWithDroppedSites++;
          out.set(pf.filePath, {
            ...pf,
            ...(flow.dropped === 0 ? {} : { callableFlowSites: flow.sites }),
            ...(chains.dropped === 0 ? {} : { referenceSites: chains.sites }),
          });
        }
      }
    }
    await maybeYieldAndGc(crossedBudget);
  }
  if (droppedSites > 0 || droppedChains > 0) {
    logger.warn(
      { droppedSites, droppedChains, files: filesWithDroppedSites },
      'parsedfile-store: dropped malformed/over-bound sites at load; files retained without those facts',
    );
  }
  if (rejectedFiles > 0) {
    logger.warn(
      { rejectedFiles },
      'parsedfile-store: rejected shard entries at load (untrusted shape); those files re-extract every run',
    );

View on GitHub (pinned to 0d1aed942f)

Solutions

Run a full re-analyze so the current writer rewrites the shards under current bounds
Check the files field: the same file(s) appearing every warm load points at a bound mismatch worth reporting with your versions
Re-verify graph answers for the affected files after the rewrite if their precision matters

Defensive patterns

Strategy: validation

Validate before calling

// After each warm load, compare dropped-file sets across runs: identical
// sets on consecutive loads mean permanent fact loss (files are retained, so
// they never re-extract) — schedule a full re-analyze.
if (intersection(lastDroppedFiles, currentDroppedFiles).length > 0) {
  await fullReanalyze(repoPath);
}

Prevention

Watch for this warning repeating with the same files across warm loads
Re-analyze after upgrading versions that touched parsing or bounds
Treat dropped facts as missing data in any downstream reasoning

When it happens

Trigger: Warm-loading an index whose serialized sites fail current sanitation — validation bounds changed between the writer and reader versions, or shard bytes are corrupted on disk. The structured fields droppedSites, droppedChains, and filesWithDroppedSites quantify the impact.

Common situations: Upgrading GitNexus across versions whose validation bounds differ; partially corrupted shard files after a crash; pathological source files whose extracted facts now exceed limits. Graph answers for the affected files quietly lose the dropped facts until a rewrite.

Understand the failure class

Parsing and encoding errors: unexpected token, malformed input — why parsers reject input and how to find the real culprit.

Related errors

AI-assisted analysis of abhigyanpatwari/GitNexus@0d1aed942f (2026-08-20). Data as JSON: /api/errors/5f5dff2103d1cb2a. Report an issue: GitHub.