Start with the observable change
A useful review summary tells you what happens differently, under which conditions, and why it matters. A file list gives you somewhere to look. A behavior statement gives you something to verify.
Consider gRPC-Go pull request #9299, which changes redirect handling during a security token exchange. We opened it in Diff it and inspected the completed analysis at commit c9650af. Here is the behavior it explained, followed by the source we used to check that explanation.
The package’s HTTP client could follow a redirect during token exchange.
The client refuses redirects. The existing response handling rejects the non-success response.
The important review question is whether a token exchange can send its request body to a redirected destination.
See what Diff it found
Diff it identified one capability: refusing HTTP redirects for STS token exchange. Its before-and-after scenario connects a redirected POST to the changed outcome: the client refuses the redirect, avoids replaying the request, and returns an error.
The review exposed seven source citations. Expanding the scenario revealed the redirect callback and regression-test lines at the reviewed commits, so we could inspect the explanation’s support.
Its two suggested checks were both unverified. The source limits also reported bounded excerpts and a rejected generated claim. That is why the next step is to read the evidence: this analysis does not establish that tests ran or that every behavior was covered. We did not run the upstream gRPC tests ourselves.
Open this PR in Diff it to inspect it yourself; GitHub sign-in is required. Your analysis may differ if the model or available context changes.
Follow the evidence through the call path
The pinned implementation adds a redirect callback that returns http.ErrUseLastResponse. The exchange code then handles that response as an error.
The regression test at the same commit sets up a server that redirects to a second server. It checks that the exchange errors and the second server receives no request. That test uses HTTP 307; it does not individually exercise every redirect status.
Read the caller as well as the changed function. Refusing a redirect is only part of the story: the caller’s response handling determines whether the failure is visible, silently ignored, or retried. Pinning both links to one commit keeps this explanation tied to the code being reviewed.
Write a review another person can check
For your next PR, try this four-part note:
- Trigger: the input, state, or event that reaches the changed path.
- Before → after: the observable result on each revision.
- Evidence: the implementation, caller, and relevant test at the reviewed commits.
- Open check: a consequential assumption that the evidence does not yet settle.
For this example, a follow-up check would be to examine ordinary successful exchanges and the intended redirect policy together. A test of the blocked path alone does not describe the whole client contract.
Diff it organizes review explanations around behavior and source evidence. Explore the interactive demo to see that format with illustrative fixture data. The demo is separate from this gRPC example.