Deep Dive: How PR Blast Radius Analysis Works

A technical look at how CodeDig calculates the blast radius of a pull request — from symbol resolution and dependency graph traversal to impact scoring.

What Is Blast Radius?

When a developer changes a function, class, or module, the immediate diff only tells part of the story. Blast radius is the set of all downstream consumers that could be affected by the change. If you rename a public API method, the blast radius includes every caller of that method — across files, across modules, and potentially across services.

Most code review focuses on the diff itself: Does the logic look correct? Are there obvious bugs? But the diff does not show you who calls the code you changed, or how many downstream services depend on the behavior you just modified. Blast radius analysis fills that gap.

Step 1: Symbol Resolution

The first step is building a symbol table for the repository. CodeDig parses source code across all supported languages (C#, TypeScript, Rust, Python, Java, Go) and resolves every symbol — function definitions, class declarations, module exports, type aliases, and more.

For each symbol, we record: - Fully qualified name (e.g., PaymentService.processRefund) - File path and line range - Kind (function, class, interface, type, module, etc.) - Visibility (public, private, internal, exported)

This is similar to what a language server does, but optimized for batch analysis across the entire repository rather than real-time editor features.

Step 2: Building the Dependency Graph

With the symbol table in hand, we construct a directed graph of dependencies. For every symbol, we identify: - Callers — other symbols that invoke or reference this symbol - Callees — symbols that this symbol invokes or references - Type dependencies — symbols connected through type parameters, return types, or field types - Module dependencies — import/export relationships between files and modules

The result is a graph where nodes are symbols and edges represent dependency relationships. For a mid-size repository (100K–500K lines of code), this graph typically contains tens of thousands of nodes and hundreds of thousands of edges.

Step 3: Diff-Driven Traversal

When a pull request is opened, CodeDig identifies the set of changed symbols — symbols whose definition was modified, added, or deleted in the diff.

For each changed symbol, we perform a breadth-first traversal of the dependency graph in the caller direction. This gives us the transitive set of all consumers that could be affected by the change.

The traversal is bounded by configurable depth limits and visibility boundaries. A change to a private helper function has a smaller blast radius than a change to a public API method, because the private function can only be reached through a shorter call chain.

Step 4: Impact Scoring

Not all blast radius entries are equally important. A downstream consumer that directly calls the changed function is more likely to be affected than a consumer five call-chain hops away. CodeDig assigns an impact score to each affected symbol based on:

• Distance — How many edges separate the affected symbol from the changed symbol
• Criticality — Whether the affected symbol is in a critical path (payments, auth, data persistence)
• Change type — Signature changes (parameter types, return types) propagate more risk than implementation-only changes
• Historical patterns — If changes to this symbol have caused failures before, the risk multiplier is higher

The aggregate blast radius score is reported on the PR along with the list of most-impacted consumers.

Step 5: Rendering the Report

The final step is rendering the analysis into a GitHub PR comment that reviewers can act on. The comment includes:

• Total blast radius count (number of affected downstream consumers)
• Top affected consumers with impact scores
• API change detection (breaking vs. non-breaking)
• Recommended actions (add tests, update documentation, notify downstream teams)

The goal is to give the reviewer the full risk picture in under 30 seconds, with enough detail to make an informed approval decision.

Performance

Blast radius analysis runs incrementally. We do not rebuild the entire dependency graph on every PR. Instead, we maintain a persistent symbol index that is updated as the repository evolves. The PR analysis only processes the changed files and traverses the existing graph from the changed symbols outward.

For most PRs, the full analysis — symbol resolution, graph traversal, impact scoring, and report generation — completes in under 30 seconds.

Try It Yourself

Install the CodeDig GitHub App and open a pull request that touches a widely-used function. The blast radius report will show you exactly how far the change ripples through your codebase.