Deduplicate review dispatches for the same HEAD SHA

[fullsend-ai-retro]

What happened

PR #880 received 6 review agent runs. Two of them (Previous Run 4 and Previous Run 5 in the review bot's comment) reviewed the same HEAD SHA 091e5c6f, producing near-identical findings and both approving. This appears to have been caused by two rapid pull_request_target synchronize events for the same push, both dispatching before the concurrency group could cancel the earlier run.

What could go better

The review agent should not re-review a SHA it has already reviewed. The concurrency group (cancel-in-progress: true) helps when runs overlap temporally, but doesn't prevent a second dispatch that arrives after the first completes. Confidence: high — the evidence of two runs on the same SHA with identical findings is clear in the bot's own comment history.

Proposed change

In the review dispatch workflow (or the review agent's entry logic), add a check before starting the review: query the PR's existing review bot comments for whether the current HEAD SHA has already been reviewed. If a review for this SHA exists, skip the run and exit early. This could be implemented as a pre-step in the review workflow that runs gh api repos/{repo}/issues/{pr}/comments and checks for the HEAD SHA in the bot's existing comments. Alternatively, add SHA-level deduplication to the concurrency group key (e.g., fullsend-review-{repo}-{pr}-{sha}) so that duplicate dispatches for the same SHA are caught.

Validation criteria

On the next 10 PRs reviewed by fullsend in this repo, no HEAD SHA should appear more than once in the review bot's comment history. Monitor by checking for duplicate SHA references in the collapsed 'Previous runs' sections of review comments.

---

Generated by retro agent from konflux-ci/konflux-ui#880

[fullsend-ai-triage]

Triage Summary

This issue describes duplicate review agent runs when two pull_request_target synchronize events fire for the same push, producing identical reviews for the same HEAD SHA.

Root cause: The review concurrency group is keyed on repo + PR number but not on SHA. When two dispatches arrive for the same SHA without temporal overlap, both execute. The pre-fetch-prior-review.sh script already extracts the prior reviewed SHA and passes it as PRIOR_REVIEW_SHA, but no workflow step gates execution on a SHA match.

Recommended fix: Add an early-exit step in reusable-review.yml (after the pre-fetch-prior-review step) that compares PRIOR_REVIEW_SHA to the current PR HEAD. If they match and provenance is app-verified, skip the review agent. This leverages existing infrastructure with minimal change.

Alternative: include SHA in the concurrency group key (fullsend-review-{repo}-{PR}-{sha}), though the workflow-level skip is preferred as it avoids consuming a runner slot.

Relationship to #1408: That issue covers duplicate retro dispatches from queued shim runs on PR close — a different stage with a different root cause. Both share the dispatch deduplication theme but require separate fixes.

Proposed test case:

Scenario: Skip review when HEAD SHA already reviewed
  Given a PR with an existing review bot comment for SHA abc1234
  And the current PR HEAD is abc1234
  When the review workflow runs
  Then it exits early without invoking the review agent

Scenario: Run review when HEAD SHA is new
  Given a prior review for SHA abc1234
  And the current PR HEAD is def5678
  Then the review agent executes normally

Edge cases:
  - First review (no prior comment) -> always run
  - Unverifiable provenance -> always run
  - /fs-review slash command -> consider force-review override

---

Labels: Review agent dispatch deduplication bug affecting the review workflow and dispatch/scaffold areas, medium priority based on resource waste without functional impact.

[fullsend-ai-prioritize]

RICE Priority Score: 1.2

Score breakdown

Dimension	Score	Reasoning
Reach	1.5	Affects all repos using the fullsend review agent — any PR with rapid push events can trigger duplicate reviews. This spans multiple customers and orgs, but is intermittent rather than constant, so scoring at 1.5.
Impact	0.5	Low functional impact: duplicate runs produce identical findings and both approve. The main cost is wasted runner resources and minor noise in the PR comment history. No blocking or degraded workflow — easy workaround of ignoring the duplicate.
Confidence	0.8	High confidence. The issue is well-documented with specific evidence (PR #880, two runs on SHA 091e5c6f). The triage comment identifies the exact fix location (reusable-review.yml after pre-fetch-prior-review step) and confirms existing infrastructure (PRIOR_REVIEW_SHA) can be leveraged.
Effort	0.5	Simple fix leveraging existing infrastructure. The PRIOR_REVIEW_SHA is already extracted by pre-fetch-prior-review.sh; the fix is adding a conditional early-exit step comparing it to the current HEAD SHA in the review workflow. Well-scoped, single-file change.

Formula: (1.5 x 0.5 x 0.8) / 0.5 = 1.2