abhigyanpatwari/GitNexus · warning

Cross-file route extraction failed for ${rootPath}

Error message

Cross-file route extraction failed for ${rootPath}

What it means

During the parse phase, language providers that implement discoverRootRouteFiles/extractRoutes run cross-file framework route extraction: each discovered root route file is parsed with parseSourceSafe, then provider.extractRoutes(rootTree, rootPath, reader, parser) walks it (following include()/reader reads). A throw from inside a provider on one root is deliberately isolated — the catch warns 'Cross-file route extraction failed for ${rootPath}' and moves to the next root, mirroring the worker's per-file isolation so one misbehaving provider cannot abort the whole analyze.

Source

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

    for (const rootPath of rootPaths) {
      const rootContent = reader(rootPath);
      if (rootContent === null) continue; // skip this root only, not the language

      let rootTree: Parser.Tree;
      try {
        rootTree = parseSourceSafe(parser, rootContent);
      } catch {
        logger.warn(`Skipping unparseable root route file: ${rootPath}`);
        continue; // skip this root only
      }

      // Isolate a misbehaving provider: a throw here must not abort the whole
      // analyze (mirrors the worker's per-file isolation). Skip this root, warn.
      try {
        const routes = provider.extractRoutes(rootTree, rootPath, reader, parser);
        for (const r of routes) out.push(r);
      } catch (err) {
        logger.warn({ err }, `Cross-file route extraction failed for ${rootPath}`);
      }
    }
  }

  return out;
}

/**
 * Handle a worker-pool startup failure by FAILING FAST with the captured cause
 * (#1741). The pool self-heals *transient* worker crashes on its own — a
 * bounded, jittered startup restart loop (see worker-pool.ts) — so this is
 * reached only when that self-heal is EXHAUSTED, or a deterministic crash-loop
 * was detected, or the pool could not even be constructed. In every such case
 * the workers genuinely cannot start.
 *
 * There is no sequential parser to silently degrade to — that fallback was
 * removed (and it had masked a worker-startup regression as a 2-hour "stuck"
 * run in #1741, rc99: a dropped `logger.warn` plus an unbounded sequential

View on GitHub (pinned to 0d1aed942f)

Solutions

  1. Inspect the { err } field in the log entry for the provider's stack trace
  2. Simplify or normalize the offending root route file toward static, framework-idiomatic route declarations
  3. Check whether your framework/version is covered by the language provider's route extractor
  4. Report the file plus stack upstream — routes from the other roots were still extracted
Defensive patterns

Strategy: fallback

Try / catch

try {
  const routes = provider.extractRoutes(rootTree, rootPath, reader, parser);
  out.push(...routes);
} catch (err) {
  logger.warn({ err }, `Cross-file route extraction failed for ${rootPath}`); // isolate one root, keep the rest
}

Prevention

When it happens

Trigger: provider.extractRoutes throwing on a specific root: a route config written in a style the provider does not model (dynamic requires, spread of imported arrays, build-time codegen), an unexpected AST shape in the parsed root tree, or reader returning content the provider mishandles.

Common situations: Framework route configs that are unusual or generated; monorepos where one project root is exotic while others are standard; framework version drift between the app's router patterns and the provider's expectations.

Related errors


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