How to Find a Pull Request’s Blast Radius

A pull request’s blast radius is the code and documented behavior it affects outside the lines it touches.

The diff may change only one branch in a request handler, but that branch can alter a public default, invalidate documentation, or change which application callback runs. None of those consequences has to appear in the changed files.

A reviewer can find much of this blast radius with repository search. The difficult part is knowing what to search for and deciding which results represent contracts the pull request should also update.

Fastify pull request #6716 provides a useful worked case. The code change was intentional, but its effect extended into unchanged documentation and release communication.

The behavior that changed

The pull request changed how Fastify handles over-long URL parameters.

Before the change, those requests could reach an application’s not-found handler and receive a 404 response. After the change, Fastify returned 414 for every application, including applications whose own not-found handler previously answered the request.

That new status was intentional. It addressed issue #6697.

The implementation was therefore not an accidental reversal that needed to be removed. The missed consequence was that the repository’s server documentation still said the not-found route is invoked. The pull request changed the documented behavior without changing that line or adding a release note.

This distinction matters during review. A changed contract is not automatically a code regression. It can be an intentional change whose documentation, tests, examples, or release notes have not caught up.

Start with what the diff changes

The first step in a manual blast-radius review is to list the meaningful things changed by the diff.

Do not limit the list to function names. Include:

• Symbols with new behavior.
• Changed signatures or return values.
• Interfaces or abstract methods whose contracts changed.
• Defaults that now select a different path.
• Status codes, error messages, or string values that callers may depend on.
• Removed or renamed symbols.
• Documented behavior affected by a new condition.

For the Fastify pull request, the important item was not merely a modified internal branch. The observable default changed: an over-long URL parameter would now produce 414 instead of being handled as not found.

Write that effect down in plain language before searching. “Over-long URL parameters now return 414 instead of reaching the not-found handler” produces better searches than a vague note such as “routing changed.”

Search for each affected relationship

Search the whole repository for every symbol, default, and behavior on the list.

For a changed method, look for its callers. If its signature changed, check whether each caller still supplies valid arguments and handles the result.

For an interface or abstract method, find every implementation. A change that is valid in one implementation may violate another.

For an overridable method, inspect subclass overrides. An added call can resolve to an override outside the diff, giving the new line behavior that is not visible in the patch.

For removed or renamed code, search for direct references and string references. Configuration, templates, documentation, and framework conventions may refer to a name without using a statically visible call.

Then search the documentation using the behavior itself. In this case, terms around “not found,” URL parameters, and routing could reveal statements about which handler runs.

Repository search is intentionally broad at this stage. A hit is not yet a defect. It is a candidate relationship that needs to be checked against the new behavior.

Compare the documentation with the new default

The next step is to read the relevant documentation as a contract, not as background material.

Ask:

• Does it state what happens by default?
• Does it name a handler, callback, status, or error that has changed?
• Would a reader following it expect the old behavior?
• Does an example depend on the path the pull request bypasses?

In fastify#6716, the unchanged documentation still said the not-found route is invoked. That statement no longer covered over-long URL parameters after the pull request.

The correct review finding was therefore narrow: the new 414 behavior was intentional, but the documentation and release note needed to reflect it.

Calling the code change itself a regression would misstate the intent. Ignoring the documentation would miss a real part of the pull request’s blast radius.

Decide which search hits belong in the pull request

Not every reference needs to change. For each result, trace the concrete effect of the diff and classify it.

A hit belongs in the pull request when the changed behavior makes it false, invalid, or misleading. Examples include a caller that no longer matches a signature, an implementation that no longer satisfies a contract, or documentation that promises the old default.

A hit may remain unchanged when it refers to a different path, explicitly describes legacy behavior, or still holds under the new condition.

The reviewer should be able to connect any requested change through a short chain:

1. The diff changes this behavior or contract.
2. This unchanged code or documentation depends on the old version.
3. The pull request should update it, or explicitly explain why it remains correct.

That chain keeps blast-radius review grounded. It prevents repository search from becoming a list of loosely related files.

What happened in the automated review

One of two Veridu reviewers searched the Fastify repository, found the documentation line, and flagged it. The finding called the change a regression, which was wrong about the intent. It was right that a documented contract had changed.

The other reviewer did not find the documentation issue.

The case shows both the value and the limit of search-based review. Searching outside the diff can expose a missed consequence. It does not guarantee that every reviewer will retrieve the same evidence or interpret the author’s intent correctly.

The full review shows the result.

What Veridu automates for PHP pull requests

For pull requests changing only PHP, Veridu traces several kinds of relationships before review:

• Subclasses that override a method the diff now calls.
• Callers of changed signatures.
• Implementations of changed interfaces or abstract methods.
• References to removed code.

Our Laravel example shows the first kind: an override in a file the pull request never touched.

The tracing is a capped text search, not a call graph. Dynamic calls and framework indirection, including facades, container bindings, and event listeners, can still be missed.

For other languages, the agent reviewers search the checkout themselves with bounded tools. Findings that cannot be grounded in the repository are dropped.

The two reviewers also remain independent. A merge is blocked only when both report the same defect at or above the blocking threshold. One reviewer finding a possible blast-radius problem is evidence for a human to inspect, not enough by itself to block the merge.

Use automation as a bounded second pass

A practical review can combine both approaches.

First, describe the behavior changed by the pull request. Search its symbols, callers, overrides, implementations, string references, defaults, and documentation. Decide which results depend on the old contract.

Then use automated change-impact analysis as another bounded search over the repository. It can retrieve relationships outside the patch and give reviewers evidence they might otherwise lack. It cannot infer every dynamic connection or settle questions of intent without repository evidence.

The goal is not to attach every nearby file to the review. It is to find the smallest set of unchanged code and documentation whose meaning changed with the diff.

See Veridu’s change-impact analysis for the current scope, or inspect the public review demo. Reviews of public GitHub repositories are free for 20 pull requests a month.