---
name: analysis-subsystems
description: How Infigraph's multi-repo/group mode and taint analysis work internally — HTTP contract extraction heuristics, cross-service edge linking, combined-graph merge, remote mode, plus taint's line-based tracking and sanitizer heuristic. Use when working on crates/infigraph-core/src/multi/ or src/taint/, or investigating taint/cross-service false positives.
---

# Analysis subsystems

Two independent analysis passes over the graph, grouped here since each has real non-obvious complexity worth knowing before touching it.

## Multi-repo groups

Core logic: `crates/infigraph-core/src/multi/`. One of the least AST-driven subsystems — much of the contract-extraction and cross-service-linking logic is string/regex heuristics, not tree-sitter queries.

**Contract extraction** — tiered, most-confident-first: use an already-detected `Route` symbol if one exists, else fall back to decorator/docstring pattern matching, else scrape router-prefix patterns from raw source. Only add lower-tier patterns for frameworks the route-detection pass doesn't already cover.

**Cross-service linking** — matches dynamic URLs (including templated/interpolated ones) against known routes, with self-match suppression and method-preference fallback, to build `CALLS_SERVICE` edges across repos.

**Combined-graph merge** — per-repo graphs merge via a bulk export/prefix/import pipeline rather than row-by-row inserts, for performance at scale. ID-prefixing conventions differ between node and edge tables — a new node/edge type must follow the existing convention exactly, or it produces dangling references silently.

**Remote mode** (`--features remote`) swaps the graph store/registry backends and enables parallel multi-repo indexing (impossible in local single-writer mode). Any new `multi/` feature should consider whether it needs a remote-mode branch, or it may silently no-op or violate single-writer assumptions under concurrent writes.

## Taint analysis

Core engine: `crates/infigraph-core/src/taint/`. `concerns/` and `reflection/` are separate, simpler pattern scanners — not part of this engine.

**Important: line-based, not real dataflow.** The intra-procedural analyzer scans line by line, tracking tainted variables through a heuristic assignment parser — not a true AST/dataflow analysis. Sink sanitization is decided by a **proximity heuristic** (a sanitizer pattern within a few lines of a sink counts as covering it), not precise flow tracking. This is the most common source of both false positives and false negatives — calibrate expectations before "fixing" what looks like an inaccurate heuristic; it's coarse by design.

**Adding a source/sink/sanitizer**: these are per-language string pattern tables keyed by category. A sink and its sanitizer must share the same category key to be linked — adding one without the other means that sink can never be marked sanitized.

**Intra- vs inter-procedural**: intra-procedural gives full path/sanitization detail within one function. Inter-procedural does a depth-bounded BFS over the call graph to connect a source-containing function to a sink-containing function across functions, but carries no path/sanitization detail — it only reports that a connection could exist.

**Known limitations (by design)**: string-substring matching (no real AST/types) plus the proximity heuristic mean both false positives and false negatives are expected. A precision fix here usually means real dataflow tracking, a much bigger change than tuning the heuristic.