What happened
On PR #2446, the PR author (ggallen) replied to 11 review findings individually between 15:26:37 and 15:26:59 UTC on June 22. Each reply was submitted as a separate GitHub pull_request_review event with state COMMENTED. This triggered 11+ fullsend.yaml workflow runs on the worktree-adr-0045-review branch within 22 seconds (visible in the fullsend.yaml run history). The concurrency group mechanism cancelled most of them, but several ran to completion, dispatching redundant review agent runs. The review bot also ran 5 times total across different commits/triggers for this single-commit PR.
What could go better
The fullsend.yaml workflow dispatches review agents on pull_request_review events without distinguishing between review states. A COMMENTED review — especially one that is a reply to existing findings — does not change the code and should not trigger a code re-review. Only APPROVED and CHANGES_REQUESTED reviews (and possibly initial COMMENTED reviews with substantive body content) warrant re-dispatch.
Existing issues address related but distinct triggers: #1014 covers debouncing synchronize (push) events, #981 covers concurrency groups for dispatch-review, and #1362 covers filtering bot-triggered label events. None specifically address filtering COMMENTED review events, which are the most common source of fan-out when reviewers reply to findings.
Confidence: High that this is a real problem (clear evidence of 11 redundant dispatches in 22 seconds). Medium confidence on the exact fix — filtering by review state is the simplest approach, but there may be edge cases where a COMMENTED review contains actionable feedback the review agent should incorporate.
Proposed change
In the fullsend.yaml workflow's review dispatch job, add a condition that skips dispatch when github.event.review.state == 'commented'. The dispatch should only fire for approved or changes_requested review states, and for pull_request_target / push events (which already indicate code changes).
Alternatively, if COMMENTED reviews sometimes carry actionable human feedback that should trigger re-review, implement a debounce: batch pull_request_review events within a short window (e.g., 60 seconds) and dispatch only once after the window closes. This would handle the reply-storm pattern while preserving responsiveness to substantive comments.
The change lives in .github/workflows/fullsend.yaml in the source repo (fullsend-ai/fullsend) and potentially in internal/scaffold/fullsend-repo/.github/workflows/dispatch.yml for scaffolded repos (per AGENTS.md, these share routing logic and must stay in sync).
Validation criteria
On the next 5 PRs where a reviewer replies to multiple inline findings, verify that (a) only 1 review dispatch occurs (not N dispatches for N replies), and (b) no legitimate review triggers are lost (an APPROVED or CHANGES_REQUESTED review still dispatches correctly). Monitor the fullsend.yaml run history for fan-out patterns — cancelled runs from concurrency groups should decrease measurably.
Generated by retro agent from #2446
What happened
On PR #2446, the PR author (ggallen) replied to 11 review findings individually between 15:26:37 and 15:26:59 UTC on June 22. Each reply was submitted as a separate GitHub
pull_request_reviewevent with stateCOMMENTED. This triggered 11+fullsend.yamlworkflow runs on theworktree-adr-0045-reviewbranch within 22 seconds (visible in the fullsend.yaml run history). The concurrency group mechanism cancelled most of them, but several ran to completion, dispatching redundant review agent runs. The review bot also ran 5 times total across different commits/triggers for this single-commit PR.What could go better
The
fullsend.yamlworkflow dispatches review agents onpull_request_reviewevents without distinguishing between review states. ACOMMENTEDreview — especially one that is a reply to existing findings — does not change the code and should not trigger a code re-review. OnlyAPPROVEDandCHANGES_REQUESTEDreviews (and possibly initialCOMMENTEDreviews with substantive body content) warrant re-dispatch.Existing issues address related but distinct triggers: #1014 covers debouncing
synchronize(push) events, #981 covers concurrency groups for dispatch-review, and #1362 covers filtering bot-triggered label events. None specifically address filteringCOMMENTEDreview events, which are the most common source of fan-out when reviewers reply to findings.Confidence: High that this is a real problem (clear evidence of 11 redundant dispatches in 22 seconds). Medium confidence on the exact fix — filtering by review state is the simplest approach, but there may be edge cases where a
COMMENTEDreview contains actionable feedback the review agent should incorporate.Proposed change
In the
fullsend.yamlworkflow's review dispatch job, add a condition that skips dispatch whengithub.event.review.state == 'commented'. The dispatch should only fire forapprovedorchanges_requestedreview states, and forpull_request_target/pushevents (which already indicate code changes).Alternatively, if
COMMENTEDreviews sometimes carry actionable human feedback that should trigger re-review, implement a debounce: batchpull_request_reviewevents within a short window (e.g., 60 seconds) and dispatch only once after the window closes. This would handle the reply-storm pattern while preserving responsiveness to substantive comments.The change lives in
.github/workflows/fullsend.yamlin the source repo (fullsend-ai/fullsend) and potentially ininternal/scaffold/fullsend-repo/.github/workflows/dispatch.ymlfor scaffolded repos (per AGENTS.md, these share routing logic and must stay in sync).Validation criteria
On the next 5 PRs where a reviewer replies to multiple inline findings, verify that (a) only 1 review dispatch occurs (not N dispatches for N replies), and (b) no legitimate review triggers are lost (an APPROVED or CHANGES_REQUESTED review still dispatches correctly). Monitor the fullsend.yaml run history for fan-out patterns — cancelled runs from concurrency groups should decrease measurably.
Generated by retro agent from #2446