On a huge pull request, rank findings by severity and confidence, comment on the top few, put the rest in a summary, and suggest splitting the change if it is mixing unrelated work. Dumping hundreds of inline comments buries real problems and stalls the review.
Why large changes break comment design
A normal comment strategy assumes a handful of findings. A migration, a vendor update or a generated code drop can produce hundreds. Each one adds a notification and a thread. The author scrolls, loses the thread, and merges with unresolved noise or gives up.
Large changes also hide risk from human reviewers. People skim a 4,000 line diff. The bot's job is to point at the few places that deserve a closer look.
A playbook
- Rank. Sort by severity, then confidence, then whether the code is reachable.
- Cap. Post the top five to ten inline, and say how many more exist.
- Summarise. Put the full list in the job summary with counts by rule and file.
- Separate old from new. Gate on findings introduced by the change, not on debt in files it merely touched.
- Say what was skipped. If the scan hit a time or size limit, state it plainly.
| Findings count | Suggested behaviour |
|---|---|
| Up to 10 | Inline comments as normal |
| 11 to 50 | Top ten inline, grouped by rule, summary for the rest |
| Over 50 | Top ten inline, one summary, suggest splitting the change |
These bands are a starting suggestion and should be tuned from your own data.
Know your platform limits
Tools have ceilings. GitHub's SARIF documentation says a run can include up to 25,000 results, but only the top 5,000 are kept, prioritised by severity. The Checks API limits annotations to 50 per request. If your volume can exceed these, design the output so the most important items are the ones that survive, and check what your own tooling does when it reaches a limit.
Suggest splitting, once
If a pull request mixes a dependency upgrade, a refactor and a feature, say so in one line and propose a split. Smaller changes are easier to review for security too. Do not nag: make the suggestion once, and respect the answer.
Our post on pull request size and security review goes deeper on why size matters.
Handle timeouts honestly
If a scan cannot finish in your time budget on a huge change, do not report a clean pass. Report that coverage was partial, list what was scanned, and either queue a full scan out of band or fail closed for sensitive paths. A fast green check on an incomplete scan is the most misleading outcome you can produce.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how filtering by reachability shrinks a long list, which is the same move you want on a large diff.
Safeguard reachability analysis is built to reduce long finding lists to the ones that matter. A free scan shows the effect on your code.
Quick check
Should a huge pull request be blocked automatically?
Size alone is a weak reason. Block on findings that meet your gate, and use size as a prompt to ask whether the change should be split.
What if the scan times out?
Report partial coverage clearly. For sensitive paths, treat an incomplete scan as a failure until a full run finishes.
Sources
Last reviewed: 19 October 2026.
