# `get_impact_radius` vs `get_review_context` in code-review-graph: Functional Differences Explained

> Understand the functional differences between get_impact_radius and get_review_context in code-review-graph. Discover how get_review_context enhances graph analysis with actionable insights.

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

---

**`get_impact_radius` performs pure graph analysis to identify affected code nodes, while `get_review_context` builds on that analysis to deliver a complete review package with source snippets and actionable guidance.**

Both tools are part of the [`code-review-graph`](https://github.com/tirth8205/code-review-graph) knowledge-graph suite for automated code review. They share underlying graph traversal logic but serve fundamentally different purposes in a review pipeline. Understanding when to use each tool helps you build efficient CI workflows and reviewer-friendly interfaces.

## Core Purpose: Graph Analysis vs. Review Package Assembly

The primary functional difference lies in their scopes:

- **`get_impact_radius`** — Computes the **blast radius** of code changes. It answers "what breaks?" by traversing dependency edges from changed files to identify impacted nodes.
- **`get_review_context`** — Assembles a **token-efficient review payload**. It answers "what should a reviewer focus on?" by wrapping impact analysis with source excerpts, risk scoring, and actionable hints.

This distinction makes `get_impact_radius` ideal for downstream automation, while `get_review_context` targets human reviewers or LLM-based review agents.

## Source Implementation and Data Flow

### `get_impact_radius` in [`code_review_graph/tools/query.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/tools/query.py)

The core implementation resides in lines 107–119 of [`query.py`](https://github.com/tirth8205/code-review-graph/blob/main/query.py). The tool calls the graph store's native `get_impact_radius` method and returns raw structural data:

```python

# From code_review_graph/tools/query.py (lines 107-119)

def get_impact_radius(
    changed_files: List[str],
    max_depth: int = 2,
    detail_level: str = "standard",
    # ... additional params

) -> Dict[str, Any]:
    # Direct graph store invocation

    result = store.get_impact_radius(changed_files, max_depth=max_depth)
    # Returns: changed_nodes, impacted_nodes, edges, summary fields

```

The tool exposes **one control parameter**: `max_depth` (default 2) limits BFS traversal hops through the dependency graph.

### `get_review_context` in [`code_review_graph/tools/review.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/tools/review.py)

The implementation spans lines 26–119 of [`review.py`](https://github.com/tirth8205/code-review-graph/blob/main/review.py). This tool **calls `get_impact_radius` internally** then layers on additional processing:

```python

# From code_review_graph/tools/review.py (lines 26-119)

def get_review_context(
    changed_files: List[str],
    max_depth: int = 2,
    include_source: bool = True,
    max_lines_per_file: int = 150,
    detail_level: str = "standard",
    # ... additional params

) -> Dict[str, Any]:
    # Step 1: Obtain impact radius via store

    impact = store.get_impact_radius(changed_files, max_depth=max_depth)
    
    # Step 2: Estimate token cost

    token_estimate = estimate_tokens(impact)
    
    # Step 3: Extract source snippets (if enabled)

    snippets = extract_source_snippets(changed_files, max_lines_per_file)
    
    # Step 4: Generate review guidance

    guidance = generate_review_guidance(impact, test_coverage_data)
    
    # Returns: wrapped context with risk, test_gaps, next_tool_suggestions

```

**Additional control parameters** in `get_review_context`:
- `include_source` — Toggle source snippet extraction
- `max_lines_per_file` — Cap snippet size for token efficiency

## Return Structure Comparison

The output schemas reveal the functional gap between these tools:

### `get_impact_radius` Output

```json
{
  "status": "ok",
  "summary": "Blast radius for 2 changed file(s): 3 functions, 5 impacted dependencies",
  "changed_files": ["src/auth.py", "src/api.py"],
  "changed_nodes": [
    {"id": "auth.login", "type": "function", "file": "src/auth.py"},
    {"id": "api.validate_token", "type": "function", "file": "src/api.py"}
  ],
  "impacted_nodes": [
    {"id": "middleware.auth_check", "type": "function", "file": "src/middleware.py"}
  ],
  "impacted_files": ["src/middleware.py", "src/models/user.py"],
  "edges": [
    {"source": "auth.login", "target": "middleware.auth_check", "type": "calls"}
  ],
  "truncated": false,
  "total_impacted": 5
}

```

### `get_review_context` Output

```json
{
  "status": "ok",
  "summary": "Review context for 2 changed file(s): medium risk, 1 test gap identified",
  "context": {
    "changed_files": ["src/auth.py", "src/api.py"],
    "impacted_files": ["src/middleware.py", "src/models/user.py"],
    "graph": {
      "changed_nodes": [...],
      "impacted_nodes": [...],
      "edges": [...]
    },
    "source_snippets": {
      "src/auth.py": "def login(username, password):\n    # 15 lines...",

      "src/api.py": "def validate_token(token):\n    # 23 lines..."

    },
    "review_guidance": "1 changed function(s) lack test coverage: login. Changes impact 2 other files. Consider splitting auth logic."
  },
  "risk": "medium",
  "test_gaps": 1,
  "next_tool_suggestions": ["get_test_recommendations", "get_security_audit"]
}

```

## Use-Case Mapping: When to Use Each Tool

| Scenario | Recommended Tool | Rationale |
|----------|---------------|-----------|
| CI impact gates / downstream analysis | `get_impact_radius` | Lightweight, no source extraction overhead |
| Human code review interfaces | `get_review_context` | Includes readable snippets and guidance |
| LLM-based review agents | `get_review_context` | Pre-packaged context reduces token costs |
| Dependency audit dashboards | `get_impact_radius` | Raw graph data for custom visualization |
| Automated risk scoring pipelines | Either | `get_impact_radius` for custom scoring; `get_review_context` for built-in risk levels |

## Detail Level Behavior: Minimal Mode Differences

Both tools support `detail_level="minimal"`, but the interpretation differs:

**`get_impact_radius` with `detail_level="minimal"`**
- Returns concise summary with risk-scored counts
- Omits full node and edge lists
- Keeps structural fields (`changed_files`, `impacted_files`)

**`get_review_context` with `detail_level="minimal"`**
- **Drops source snippets entirely** regardless of `include_source` setting
- Returns high-level risk, file counts, key entities, and `next_tool_suggestions`
- Most compact payload for token-constrained environments

```python

# Minimal mode comparison

from code_review_graph.tools import get_impact_radius, get_review_context

# Impact radius: graph summary only

impact = get_impact_radius(
    changed_files=["src/auth.py"],
    detail_level="minimal"
)

# Contains: summary, total_impacted, changed_files count

# Review context: guidance without snippets

review = get_review_context(
    changed_files=["src/auth.py"],
    include_source=True,  # Ignored in minimal mode

    detail_level="minimal"
)

# Contains: summary, risk level, test_gaps, next_tool_suggestions

# Missing: context.source_snippets

```

## Practical Code Examples

### Basic Impact Analysis

```python
from code_review_graph.tools.query import get_impact_radius

result = get_impact_radius(
    changed_files=["src/auth.py", "src/api.py"],
    max_depth=2,
    detail_level="standard"
)

print(f"Affected nodes: {result['total_impacted']}")
print(f"Impact spread: {len(result['impacted_files'])} files")

```

### Complete Review Package

```python
from code_review_graph.tools.review import get_review_context

payload = get_review_context(
    changed_files=["src/auth.py"],
    max_depth=2,
    include_source=True,
    max_lines_per_file=150,
    detail_level="standard"
)

# Access structured guidance

print(f"Risk level: {payload['risk']}")
print(f"Test gaps: {payload['test_gaps']}")

# Iterate suggested follow-up tools

for tool in payload.get('next_tool_suggestions', []):
    print(f"Consider running: {tool}")

```

### Public Entry Points in [`main.py`](https://github.com/tirth8205/code-review-graph/blob/main/main.py)

Both tools are exposed through CLI/API entry points in [`code_review_graph/main.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/main.py):
- `get_impact_radius_tool`: lines 19–44
- `get_review_context_tool`: lines 88–118

## Summary

- **`get_impact_radius`** in [`code_review_graph/tools/query.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/tools/query.py) (lines 107–119) provides **raw graph analysis** — changed nodes, impacted dependencies, and traversal edges without source content.

- **`get_review_context`** in [`code_review_graph/tools/review.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/tools/review.py) (lines 26–119) **wraps the impact analysis** with source snippets, token estimates, risk scoring, and actionable guidance for reviewers.

- **Shared foundation**: Both use `store.get_impact_radius()` for graph traversal and respect `max_depth` and `detail_level` parameters.

- **Key differentiators**: `get_review_context` adds `include_source`, `max_lines_per_file`, and produces `review_guidance` and `next_tool_suggestions`.

- **Minimal mode divergence**: `get_review_context` drops source snippets entirely in minimal mode; `get_impact_radius` retains core structural data.

## Frequently Asked Questions

### What is the relationship between `get_impact_radius` and `get_review_context`?

`get_review_context` **depends on** `get_impact_radius`. It calls `store.get_impact_radius()` internally to obtain the base graph analysis, then enriches that data with source extraction and guidance generation. You cannot use `get_review_context` without the underlying impact analysis logic.

### Can I use `get_impact_radius` directly instead of `get_review_context`?

Yes. Use `get_impact_radius` when you need **only structural dependency data** — for example, to drive custom downstream tools, build visualization dashboards, or implement your own risk scoring. Use `get_review_context` when you need a **complete review payload** ready for human or LLM consumption.

### Why does `get_review_context` ignore `include_source=True` in minimal mode?

The `detail_level="minimal"` flag is designed for **maximum token efficiency**. Source snippets are the largest payload component, so they are unconditionally excluded regardless of the `include_source` parameter. This ensures predictable payload size for CI systems and constrained environments.

### Where are these tools registered in the codebase?

Public entry points are defined in [`code_review_graph/main.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/main.py): `get_impact_radius_tool` (lines 19–44) and `get_review_context_tool` (lines 88–118). The core implementations are in [`code_review_graph/tools/query.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/tools/query.py) and [`code_review_graph/tools/review.py`](https://github.com/tirth8205/code-review-graph/blob/main/code_review_graph/tools/review.py) respectively.