How Blast-Radius Analysis Traces Affected Code Across a Codebase

Blast-radius analysis traces affected code by performing a bidirectional breadth-first search across a dependency graph, starting from seed nodes in changed files and traversing both incoming and outgoing relationships to a configurable depth.

The blast-radius feature in the code-review-graph VS Code extension provides developers with a comprehensive view of code impact by mapping exactly how changes propagate through a codebase. By analyzing dependency relationships stored in a SQLite graph database, this tool identifies every function, class, and file that could be affected by modifications to specific code regions. Understanding this tracing mechanism helps developers assess the risk of changes and ensure complete test coverage.

The Three Stages of Blast-Radius Analysis

The blast-radius implementation operates through a precise three-stage pipeline that transforms raw code changes into actionable impact reports.

1. Seed Node Identification

The analysis begins by establishing seed nodes that represent the starting point of the change. When the codeReviewGraph.showBlastRadius command is invoked, the extension calls resolveNodeAtCursor to identify the specific code element under the cursor. If no specific node is selected, the system falls back to treating the entire file as the seed.

The seed set is constructed from all qualified names located within the selected scope. In src/features/blastRadius.ts, this resolution occurs between lines 45-48, where the extension extracts every definable symbol from the target file to serve as the origin points for the graph traversal.

2. Bidirectional BFS Traversal

The core traversal logic resides in SqliteReader.getImpactRadius within src/backend/sqlite.ts (lines 52-77). This method implements a breadth-first search (BFS) that explores the dependency graph in both directions:

• Forward traversal follows outgoing edges to find code that the seed depends on
• Reverse traversal follows incoming edges to find code that depends on the seed

The BFS processes multiple edge types including CALLS, IMPORTS_FROM, and TESTED_BY relationships. A maxDepth parameter controls how many hops the algorithm traverses, preventing exponential expansion in large projects. The implementation maintains a visited set to avoid cycles and redundant processing, adding newly discovered nodes to the impacted collection at each depth level.

3. Result Aggregation and Visualization

After completing the BFS, the system resolves qualified names back to full GraphNode objects and gathers distinct file paths. According to the source in src/backend/sqlite.ts (lines 82-99), the method returns a comprehensive result set containing:

• changedNodes: Nodes directly located in the changed files
• impactedNodes: All transitively affected nodes discovered during BFS
• impactedFiles: Distinct file paths containing impacted code
• edges: The specific dependency relationships connecting these nodes

The registerBlastRadiusCommand function in src/features/blastRadius.ts (lines 24-64) orchestrates this workflow, obtaining the active editor, resolving the cursor position, reading the user-configured depth, and finally updating the BlastRadiusTreeProvider to render results in the side panel.

Key Implementation Files

Understanding the architecture requires familiarity with these specific source files:

• src/features/blastRadius.ts – Registers the VS Code command and coordinates the analysis workflow
• src/backend/sqlite.ts – Contains the getImpactRadius method implementing the bidirectional BFS algorithm
• src/features/cursorResolver.ts – Provides the resolveNodeAtCursor utility for precise seed selection
• src/views/treeView.ts – Implements the BlastRadiusTreeProvider for visualizing results in the sidebar

Configuring the Analysis Depth

The maxDepth parameter is critical for managing performance and relevance. Setting depth=1 shows only direct dependencies, while higher values reveal transitive impacts. The default configuration typically uses a depth of 3, which captures most meaningful ripple effects without overwhelming the user with distant, loosely-coupled dependencies.

Practical Usage Examples

Triggering Analysis from the Editor

Execute the blast-radius command directly from VS Code to analyze the code under your cursor:

// In VS Code command palette or via keybinding
vscode.commands.executeCommand('codeReviewGraph.showBlastRadius');

Programmatic Analysis for Specific Files

For automated workflows or custom extensions, invoke the analysis programmatically:

import { SqliteReader } from 'code-review-graph-vscode/src/backend/sqlite';

// Initialize the reader with your graph database
const reader = new SqliteReader(dbPath);
const changedFiles = ['src/auth.py'];
const depth = 3;

const impact = reader.getImpactRadius(changedFiles, depth);

console.log(`Found ${impact.changedNodes.length} changed nodes`);
console.log(`Impacted ${impact.impactedNodes.length} nodes in ${impact.impactedFiles.length} files`);
console.log(`Traversed ${impact.edges.length} dependency edges`);

Focusing the Results Panel

After analysis completes, programmatically reveal the blast-radius view:

await vscode.commands.executeCommand('codeReviewGraph.blastRadius.focus');

Summary

• Blast-radius analysis uses bidirectional BFS to trace both upstream and downstream dependencies from changed code.
• The three-stage pipeline involves seed identification, graph traversal, and result aggregation.
• SqliteReader.getImpactRadius in src/backend/sqlite.ts implements the core graph-walking algorithm with configurable depth limits.
• The system tracks multiple relationship types including CALLS, IMPORTS_FROM, and TESTED_BY to provide comprehensive impact coverage.
• Results are displayed through the BlastRadiusTreeProvider in the VS Code sidebar, showing exactly which files and functions require attention.

Frequently Asked Questions

What types of dependencies can blast-radius analysis detect?

The analysis detects CALLS relationships between functions, IMPORTS_FROM relationships for module dependencies, and TESTED_BY relationships linking implementation code to test files. By traversing both directions of these edges, the system captures code that either depends on or is depended upon by the changed components.

How does the analysis handle very large codebases?

The maxDepth parameter acts as a circuit breaker to prevent exponential expansion. Users can configure this limit based on their project's architecture—typically 2-3 hops suffice for most impact assessments. Additionally, the BFS implementation tracks visited nodes to eliminate redundant processing of shared dependencies.

Can I analyze the impact of multiple files simultaneously?

Yes. The getImpactRadius method accepts an array of file paths as the changedFiles parameter. The system extracts all qualified names from each file to build a comprehensive seed set, then traces the combined impact of changes across all specified files in a single graph traversal.

What is the difference between changed nodes and impacted nodes?

Changed nodes represent code elements located directly within the files specified as changed—these are the origin points of the analysis. Impacted nodes are all other code elements discovered during the BFS traversal that have a dependency relationship (direct or transitive) with the changed nodes. This distinction helps reviewers separate the actual modifications from the potentially affected codebase surface area.

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