What happened
PR #529 was a Renovate dependency update PR in konflux-ci/build-service, open from 2025-12-04 to 2026-07-03 (closed without merge). Between June 3 and July 3, the review agent ran 53 times against it (dispatch runs in konflux-ci/.fullsend). The review agent consistently approved the PR with only low-severity informational findings (dependency version skew, semver semantics for v0.x modules). Two runs (28219057677, 28436159251) failed during the post-review step. The estimated token cost of 53 review runs on an unchanging dependency bump PR is substantial.
What could go better
The primary driver of the 53 runs is a self-triggering feedback loop: the review bot submits a PR review (APPROVED or DISMISSED), which fires a pull_request_review/submitted GitHub event, which triggers the fullsend.yaml workflow in the source repo, which dispatches to the review workflow in .fullsend. The existing fullsend.yaml template filters bot-authored issue_comment events (checking github.event.comment.user.type != 'Bot'), but has no equivalent filter for bot-submitted pull_request_review events. The dispatch.yml checks for the bot name only for the 'fix' stage routing, not for the 'review' stage. This gap means every review submission by the bot can trigger another review run. Combined with Renovate's periodic force pushes (triggering pull_request_target/synchronize), this created a steady cadence of ~2 runs/day. Confidence: high — the mechanism is clearly visible in the event trigger chain and confirmed by the workflow configuration. Related issues #963, #1355, #1287, #1014 would provide additional defense-in-depth but don't address this specific dispatch-level self-trigger.
Proposed change
Add a condition to the fullsend.yaml workflow template (and the dispatch routing logic in dispatch.yml if applicable) that filters out pull_request_review events submitted by the fullsend review bot itself. Specifically:
- In the
fullsend.yaml template's job-level if condition for pull_request_review events, add: github.event.review.user.type != 'Bot' (or filter by the specific bot login fullsend-ai-review[bot]).
- Alternatively, add this filter in
dispatch.yml before dispatching to the review workflow, similar to how the fix stage already checks the bot identity.
This prevents the self-triggering loop at the source, rather than relying on the review agent to detect and skip redundant reviews (which still consumes a workflow run and some compute).
Validation criteria
After the change: (1) When the review bot submits a review on any PR, no new review workflow run should be dispatched from that event. (2) Reviews should still be triggered by human-submitted pull_request_review events (e.g., when a human requests changes). (3) On the next long-lived Renovate PR, the review run count should be bounded by the number of force pushes (synchronize events) rather than doubling from self-triggered review events. Target: review run count reduced by at least 40% on bot-authored PRs compared to the 53-run baseline observed here.
Generated by retro agent from konflux-ci/build-service#529
What happened
PR #529 was a Renovate dependency update PR in konflux-ci/build-service, open from 2025-12-04 to 2026-07-03 (closed without merge). Between June 3 and July 3, the review agent ran 53 times against it (dispatch runs in konflux-ci/.fullsend). The review agent consistently approved the PR with only low-severity informational findings (dependency version skew, semver semantics for v0.x modules). Two runs (28219057677, 28436159251) failed during the post-review step. The estimated token cost of 53 review runs on an unchanging dependency bump PR is substantial.
What could go better
The primary driver of the 53 runs is a self-triggering feedback loop: the review bot submits a PR review (APPROVED or DISMISSED), which fires a
pull_request_review/submittedGitHub event, which triggers thefullsend.yamlworkflow in the source repo, which dispatches to the review workflow in.fullsend. The existingfullsend.yamltemplate filters bot-authoredissue_commentevents (checkinggithub.event.comment.user.type != 'Bot'), but has no equivalent filter for bot-submittedpull_request_reviewevents. The dispatch.yml checks for the bot name only for the 'fix' stage routing, not for the 'review' stage. This gap means every review submission by the bot can trigger another review run. Combined with Renovate's periodic force pushes (triggeringpull_request_target/synchronize), this created a steady cadence of ~2 runs/day. Confidence: high — the mechanism is clearly visible in the event trigger chain and confirmed by the workflow configuration. Related issues #963, #1355, #1287, #1014 would provide additional defense-in-depth but don't address this specific dispatch-level self-trigger.Proposed change
Add a condition to the
fullsend.yamlworkflow template (and the dispatch routing logic indispatch.ymlif applicable) that filters outpull_request_reviewevents submitted by the fullsend review bot itself. Specifically:fullsend.yamltemplate's job-levelifcondition forpull_request_reviewevents, add:github.event.review.user.type != 'Bot'(or filter by the specific bot loginfullsend-ai-review[bot]).dispatch.ymlbefore dispatching to the review workflow, similar to how the fix stage already checks the bot identity.This prevents the self-triggering loop at the source, rather than relying on the review agent to detect and skip redundant reviews (which still consumes a workflow run and some compute).
Validation criteria
After the change: (1) When the review bot submits a review on any PR, no new review workflow run should be dispatched from that event. (2) Reviews should still be triggered by human-submitted
pull_request_reviewevents (e.g., when a human requests changes). (3) On the next long-lived Renovate PR, the review run count should be bounded by the number of force pushes (synchronize events) rather than doubling from self-triggered review events. Target: review run count reduced by at least 40% on bot-authored PRs compared to the 53-run baseline observed here.Generated by retro agent from konflux-ci/build-service#529