Enable cancel-in-progress for review dispatches on the same PR

[fullsend-ai-retro]

What happened

PR #944 had multiple review agent runs queued because the fullsend shim workflow uses cancel-in-progress: false in its concurrency group. When Renovate force-pushed twice in quick succession (e.g., at 06:13:36 on May 20), two fullsend workflow runs triggered, potentially dispatching overlapping review agent runs.

What could go better

Setting cancel-in-progress: true on the concurrency group for the review dispatch path would automatically cancel stale review runs when a new push arrives. This is standard practice for CI workflows and would prevent wasted compute on outdated commits. Confidence is high — canceling a review for a superseded commit is always safe since a new review will run on the latest commit.

Proposed change

In the fullsend shim workflow template (or documentation for shim setup), change the concurrency configuration to use cancel-in-progress: true for review-related triggers (opened, synchronize, ready_for_review). The concurrency group key should include the PR number to ensure only same-PR runs cancel each other. Example: concurrency: { group: 'fullsend-review-${{ github.event.pull_request.number }}', cancel-in-progress: true }.

Validation criteria

After the change, verify that rapid successive pushes to the same PR result in only the latest review run completing. Check that close/retro dispatches are on a separate concurrency group and are not affected.

---

Generated by retro agent from konflux-ci/project-controller#944

[fullsend-ai-triage]

Thanks for filing this. Before proceeding, there's an important architectural detail to consider: the review stage workflow (review.yml) already uses cancel-in-progress: true with a concurrency group keyed by source_repo and PR number. This means that even when two dispatch runs queue at the shim level, the second review agent run should cancel the first at the stage level.

Additionally, ADR 0034 deliberately chose cancel-in-progress: false at the shim/dispatch level to serialize dispatch routing and avoid race conditions in the routing logic.

Given this layered concurrency design, can you clarify: were duplicate review agent runs actually observed completing on the same commit in PR #944, or were the queued dispatches resolved by the existing stage-level cancellation? If the stage-level cancel-in-progress: true is already preventing duplicate reviews from completing, the proposed shim-level change may not provide additional benefit and could introduce routing race conditions that ADR 0034 was designed to prevent.

---

Labels: Issue concerns the dispatch/shim concurrency behavior for the review agent pipeline.