How Blast Radius Analysis Identifies Affected Files in Code Changes

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, 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 with impact_cmd = sub.add_parser("impact", ...)), or through the programmatic API in code_review_graph/main.py, the tool first determines what changed:

# 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 (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 implementation:

// 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:

# 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 (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 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	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 builds a directed graph from AST relationships (calls, imports, inheritance, tests)
• 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 exposes get_impact_radius for programmatic and LLM-driven queries
• 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.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}