# How Blast Radius Analysis Identifies Affected Files in Code Changes

> Discover how blast radius analysis in code reviews identifies affected files by mapping dependencies. Understand the impact of changes with this powerful technique.

- Repository: [Tirth Kanani/code-review-graph](https://github.com/tirth8205/code-review-graph)
- Tags: deep-dive
- Published: 2026-08-18

---

**Blast-radius analysis identifies affected files by traversing a directed knowledge graph from changed nodes outward through call, import, inheritance, and test edges up to a configurable depth limit.**

This technique powers the *code-review-graph* project (`tirth8205/code-review-graph`), turning static source code into a queryable graph that reveals which files and symbols propagate the effects of any code modification. Below is a complete breakdown of how this works, grounded in the actual source implementation.

## Building the Knowledge Graph from Source

Before any blast-radius computation can run, the tool constructs a comprehensive **code knowledge graph** from your repository.

In [`code_review_graph/graph.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/graph.py), the system parses source files using Tree-Sitter and extracts relationships between code elements. The resulting directed graph captures four critical edge types:

- **Call edges** — `caller → callee` relationships between functions and methods
- **Import edges** — `importer → imported` module dependencies
- **Inheritance edges** — `class → subclass` hierarchy links
- **Test edges** — `test → exercised` connections linking tests to the code they verify

This graph structure is the foundation that makes blast-radius traversal possible.

## Detecting the Initial Change Set

The blast-radius computation begins by establishing **seed nodes** — the files or symbols that have been directly modified.

When invoked via the CLI's `impact` sub-command (defined in [`code_review_graph/cli.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/cli.py) with `impact_cmd = sub.add_parser("impact", ...)`), or through the programmatic API in [`code_review_graph/main.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/main.py), the tool first determines what changed:

```python

# From the CLI: generate impact report for current changes

$ crg impact --depth 3

# The tool identifies changed files/symbols as seed nodes

# Then traverses the graph to find all reachable nodes

```

These seed nodes become the starting point for the breadth-first search that follows.

## Graph Traversal and Depth Control

The core blast-radius algorithm performs **breadth-first search (BFS)** from each seed node, following graph edges outward to discover all potentially affected code.

The traversal is governed by a configurable depth limit. As documented in the source, the environment variable `CRG_MAX_IMPACT_DEPTH` defaults to **2**, limiting how far the search propagates through the dependency chain.

This depth control is also exposed in the VS Code extension via the `blastRadiusDepth` setting in [`package.json`](https://github.com/tirth8205/code-review-graph/blob/main/package.json) (default: 2). Users can increase this value for deeper analysis when needed:

| Depth | Typical Use Case |
|-------|----------------|
| 1 | Direct callers/importers only (conservative) |
| 2 | Default: one level of transitive dependencies |
| 3+ | Deep impact analysis for critical changes |

## Filtering: From Impacted Nodes to Impacted Files

The traversal produces two distinct result sets, as seen in the VS Code extension's [`blastRadius.ts`](https://github.com/tirth8205/code-review-graph/blob/main/blastRadius.ts) implementation:

```typescript
// VS Code extension computes and displays blast radius
const impact = await getImpactRadiusTool(changedFiles);
blastRadiusProvider.setResults(impact.changedNodes, impact.impactedNodes);

```

- **`changedNodes`** — The original seed nodes (directly modified code)
- **`impactedNodes`** — All nodes reachable within the depth limit

However, the system applies an important filter: **file-level nodes are excluded from direct output**. These represent "wide" blast-radius scenarios where a change touches many downstream files. Instead, the analysis focuses on **granular symbols** that actually propagate the change, giving reviewers precise targets rather than overwhelming lists.

The `impacted_files` list is still computed and available, but the emphasis remains on symbol-level impact for actionable review guidance.

## Tool Integration and Result Presentation

The blast-radius capability is exposed through multiple interfaces in the codebase:

**Programmatic API via `get_impact_radius_tool`:**

```python

# Underlying tool used by LLM prompts and internal calls

# Located in code_review_graph/tools/query.py

from code_review_graph.tools.query import get_impact_radius

impact = get_impact_radius(changed_symbols, max_depth=2)

# Returns: changedNodes, impactedNodes, impacted_files

```

**CLI Output:**

The `impact` command in [`code_review_graph/main.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/main.py) (documented at line 227: "Analyze the blast radius of changed files in the codebase") renders results as formatted tables with warnings when the blast radius exceeds expected thresholds.

**VS Code Visualization:**

The extension's [`blastRadius.ts`](https://github.com/tirth8205/code-review-graph/blob/main/blastRadius.ts) provides tree views, highlighting, and inline decorations based on the computed impact sets.

## Configuration and Environment Variables

| Setting | Location | Default | Purpose |
|---------|----------|---------|---------|
| `CRG_MAX_IMPACT_DEPTH` | Environment | 2 | Global depth limit for all traversals |
| `blastRadiusDepth` | VS Code [`package.json`](https://github.com/tirth8205/code-review-graph/blob/main/package.json) | 2 | Extension-specific override |

These controls let teams balance analysis thoroughness against performance, as deeper traversal on large codebases increases computation time.

## Summary

- [`code_review_graph/graph.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/graph.py) builds a directed graph from AST relationships (calls, imports, inheritance, tests)
- [`code_review_graph/main.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/main.py) line 227 documents the blast-radius analysis entry point, with the CLI `impact` command providing user access
- The **BFS traversal** starts from changed nodes and follows edges up to `CRG_MAX_IMPACT_DEPTH` (default 2)
- [`code_review_graph/tools/query.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/tools/query.py) exposes `get_impact_radius` for programmatic and LLM-driven queries
- [`code-review-graph-vscode/src/features/blastRadius.ts`](https://github.com/tirth8205/code-review-graph/blob/main/code-review-graph-vscode/src/features/blastRadius.ts) visualizes results with `setResults(changedNodes, impactedNodes)`
- Output filters prioritize **symbol-level impact** over file-level lists, surfacing precise review targets

## Frequently Asked Questions

### How does blast-radius analysis differ from simple file dependency scanning?

File dependency scanning only identifies which files import or include changed files. Blast-radius analysis operates at the **symbol level**, tracing through call graphs, inheritance hierarchies, and test coverage relationships to find exactly which functions, classes, and methods could be affected — even in files that don't directly import the changed code.

### Why is the default traversal depth set to 2?

Depth 2 captures **direct callers and their immediate callers** (or importers of importers) while keeping computation fast and results interpretable. Depth 1 often misses meaningful impact; depth 3+ can explode into hundreds of files in large codebases. Teams can increase the limit via `CRG_MAX_IMPACT_DEPTH` or VS Code's `blastRadiusDepth` when analyzing critical changes.

### What triggers a "wide blast radius" warning?

When the number of **file-level nodes** in the impacted set exceeds practical review limits, the tool flags a wide blast radius. This typically indicates a change to foundational code — utilities, base classes, or common interfaces — that propagates throughout the system. Reviewers should treat these changes with extra scrutiny and consider breaking them into smaller units.

### Can blast-radius analysis work with partial or incremental code changes?

Yes. The analysis accepts any set of **changed nodes** as seeds — whether from uncommitted working directory changes, staged hunks, or comparisons between arbitrary commits. The VS Code extension computes impact for the current editor selection, while the CLI can analyze `git diff` output or specified file lists.