What happened
PR #816 triggered 14 fullsend.yaml runs and at least 10 review dispatches over its 2-day lifecycle. The runs were triggered by two event types:
pull_request_target (7 runs): Triggered by pushes, syncs, and merges — these represent new code to review.pull_request_review (7 runs): Triggered by human review submissions (approvals, comments, change requests) — these do not represent new code.
Several pull_request_review-triggered dispatches launched new review agent runs even though no code had changed since the last review. For example, when ralphbean posted approval reviews at 15:51 and 17:24, each triggered a new dispatch that re-reviewed the same commit the bot had already approved.
What could go better
The fullsend.yaml workflow should distinguish between events that introduce new code (which need re-review) and events that are human feedback signals (which may need different handling, like triggering a fix agent on changes_requested, but should not trigger a redundant review).
Specifically, pull_request_review events with action: approved or action: commented should not dispatch new review runs. Only pull_request_review events with action: changes_requested might be relevant (to trigger a fix agent), and even then, the review dispatch is unnecessary — the fix agent should be dispatched directly.
Confidence: Medium. Without access to the fullsend.yaml workflow source, I cannot confirm whether filtering already exists and failed, or whether there is no filtering at all. The observed behavior (7 review-triggered dispatches) strongly suggests no filtering. However, some of these dispatches may serve other purposes (e.g., updating sticky comments, triggering downstream workflows) that I'm not aware of.
Risk: Suppressing pull_request_review dispatches could break the fix agent workflow if it depends on the review dispatch as a trigger. The change should be tested to ensure fix agent dispatch is independent.
Proposed change
In the fullsend.yaml workflow (or the dispatch logic that decides which .fullsend workflow to trigger), add event filtering:
- For
pull_request_review events: only dispatch fix.yml (not review.yml) when the review action is changes_requested. Skip dispatch entirely for approved and commented actions.
- For
pull_request_target events with action synchronize: continue dispatching review.yml as today (new code pushed).
- For
pull_request_target events with action closed (merged): skip review dispatch (the code is already merged).
This would have reduced the 10+ review dispatches on PR #816 to approximately 4-5, saving ~50% of review agent token spend on this PR.
Validation criteria
Over the next 10 PRs in fullsend-ai/fullsend, track the ratio of review dispatches to code-changing events (pushes). The ratio should decrease from ~2:1 to ~1:1. No review should be missed for commits that actually changed code. Fix agent dispatches should continue to work correctly when humans request changes.
Generated by retro agent from #816
What happened
PR #816 triggered 14
fullsend.yamlruns and at least 10 review dispatches over its 2-day lifecycle. The runs were triggered by two event types:pull_request_target(7 runs): Triggered by pushes, syncs, and merges — these represent new code to review.pull_request_review(7 runs): Triggered by human review submissions (approvals, comments, change requests) — these do not represent new code.Several
pull_request_review-triggered dispatches launched new review agent runs even though no code had changed since the last review. For example, whenralphbeanposted approval reviews at 15:51 and 17:24, each triggered a new dispatch that re-reviewed the same commit the bot had already approved.What could go better
The
fullsend.yamlworkflow should distinguish between events that introduce new code (which need re-review) and events that are human feedback signals (which may need different handling, like triggering a fix agent onchanges_requested, but should not trigger a redundant review).Specifically,
pull_request_reviewevents withaction: approvedoraction: commentedshould not dispatch new review runs. Onlypull_request_reviewevents withaction: changes_requestedmight be relevant (to trigger a fix agent), and even then, the review dispatch is unnecessary — the fix agent should be dispatched directly.Confidence: Medium. Without access to the
fullsend.yamlworkflow source, I cannot confirm whether filtering already exists and failed, or whether there is no filtering at all. The observed behavior (7 review-triggered dispatches) strongly suggests no filtering. However, some of these dispatches may serve other purposes (e.g., updating sticky comments, triggering downstream workflows) that I'm not aware of.Risk: Suppressing
pull_request_reviewdispatches could break the fix agent workflow if it depends on the review dispatch as a trigger. The change should be tested to ensure fix agent dispatch is independent.Proposed change
In the
fullsend.yamlworkflow (or the dispatch logic that decides which.fullsendworkflow to trigger), add event filtering:pull_request_reviewevents: only dispatchfix.yml(notreview.yml) when the review action ischanges_requested. Skip dispatch entirely forapprovedandcommentedactions.pull_request_targetevents with actionsynchronize: continue dispatchingreview.ymlas today (new code pushed).pull_request_targetevents with actionclosed(merged): skip review dispatch (the code is already merged).This would have reduced the 10+ review dispatches on PR #816 to approximately 4-5, saving ~50% of review agent token spend on this PR.
Validation criteria
Over the next 10 PRs in fullsend-ai/fullsend, track the ratio of review dispatches to code-changing events (pushes). The ratio should decrease from ~2:1 to ~1:1. No review should be missed for commits that actually changed code. Fix agent dispatches should continue to work correctly when humans request changes.
Generated by retro agent from #816