fix(pr-agent): discriminate the concurrency group by event and by pr/issue

[yakimoto]

One line of YAML. This repo is one of 118 callers of 137 measured carrying the same defect.

The defect

Concurrency is evaluated at workflow level, before any job if:. A run that the pr-agent lane would go on to skip has therefore already joined the group and evicted whatever was in it. PRs and Issues also share one number sequence. So this group —

group: pr-agent-${{ github.event.pull_request.number || github.event.issue.number || github.ref }}
cancel-in-progress: true

— collapses every event touching number N onto a single key, and each new one kills the last. A comment on Issue #30 cancels the in-flight review of PR #30, then skips itself.

The fix

group: pr-agent-${{ github.event_name }}-${{ (github.event.pull_request.number || github.event.issue.pull_request) && 'pr' || 'issue' }}-${{ github.event.pull_request.number || github.event.issue.number || github.ref }}

Both discriminators are load-bearing:

• event_name stops an issue_comment cancelling the push-triggered pull_request review of the same PR. This is the common case, since that review runs on every synchronize.
• the pr/issue kind stops issue_comment on PR chore(contracts): correct false TESTING.md → declared absence (no test command) #30 colliding with issue_comment on Issue chore(contracts): correct false TESTING.md → declared absence (no test command) #30 — same event, same number, which event_name alone does not separate. Three repos carry the event-only key from an earlier pass and retain exactly this residual, so it is an observed gap rather than a hypothetical one.

Why this is not speculative

Proven live before this fan-out. claude-workstation#3617 applied this identical change to the fleet's worst case — 29 success / 1,625 cancelled / 5,735 skipped across 7,389 all-time runs — and its own pr_agent then concluded success with the agent step actually run, not cancelled and not skipped. The retry step correctly skipped because attempt 1 succeeded.

It is also the same expression already running in production on 16 repos from the wave-pen#418 wave (api-spec, wave-foundation-public, wave-realtime-edge, wave-modules, and others).

How this repo was selected

Every repo in the org was enumerated and its .github/workflows/pr-agent.yml read off its default branch — not a working tree, not a code-search index, both of which can disagree with what ships. Classification was four-valued so an unreadable repo could never render as a safe one; 0 came back unreadable, so 118 is a count and not a floor.

A repo was marked vulnerable only if it satisfies all three: it triggers on more than one numbered event, its group carries no discriminator, and cancel-in-progress is true. Repos without cancel-in-progress queue rather than evict and were left alone.

What is deliberately not in this PR

• No pin bump. Some callers pin the reusable workflow at a stale SHA and are missing separate body fixes; that is tracked apart from this and depends on wave-foundation#1258.
• No change to triggers, permissions, or the job body. The diff is the concurrency block and the comment above it.

Receipts

• The patch is applied by exact string match on the old group line. Any repo whose line did not match exactly once, directly under concurrency: was reported and skipped rather than pattern-rewritten — a regex that quietly rewrites a line it did not fully understand is how a one-line fix becomes 118 defects.
• The patched file is parsed as YAML and the resulting concurrency.group asserted to contain both discriminators before anything is written.
• No other file is touched.

Refs wave-pen#420, wave-pen#386

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

---

Note

^{Cursor Bugbot is generating a summary for commit 19394c7. Configure here.}

Summary by Sourcery

Ensure PR-agent concurrency cancellation is isolated by event and resource type to avoid unrelated runs evicting each other.

Bug Fixes:

• Prevent PR-agent workflow runs for different event types or resource kinds from cancelling one another when they share the same number.

Enhancements:

• Disambiguate workflow concurrency groups by event name and whether the numbered resource is a pull request or issue.

[codeant-ai]

🤖 CodeAnt AI — Review Status

Status	Commit	Started (UTC)	Finished (UTC)
✅ Reviewed your PR	19394c7	Aug 24, 2026 · 17:14	17:15

[sourcery-ai]

Sorry @yakimoto, you have reached your weekly rate limit of 250000 diff characters.

Please try again later or upgrade to continue using Sourcery

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_032cc592-7aad-4123-b89c-28ee5f89cd10)

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Updates the pr-agent workflow’s concurrency key to prevent unrelated pull request and issue events from cancelling one another while preserving the existing cancel-in-progress behavior.

Flow diagram for discriminated pr-agent concurrency groups

flowchart LR
    PullRequest[pull_request event] --> PRGroup[pr-agent-pull_request-pr-number]
    IssueCommentPR[issue_comment on pull request] --> PRCommentGroup[pr-agent-issue_comment-pr-number]
    IssueCommentIssue[issue_comment on issue] --> IssueGroup[pr-agent-issue_comment-issue-number]
    PRGroup --> Cancel[Cancel only matching in-flight run]
    PRCommentGroup --> Cancel
    IssueGroup --> Cancel

Loading

File-Level Changes

Change	Details	Files
Disambiguate workflow concurrency groups by triggering event and whether the numbered target is a pull request or issue.	Add explanatory comments documenting workflow-level concurrency evaluation and the two required discriminators. Include github.event_name in the concurrency key. Derive a pr/issue kind discriminator and retain the existing PR/issue number or ref fallback. Leave cancellation behavior, triggers, permissions, jobs, and workflow pins unchanged.	.github/workflows/pr-agent.yml

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[coderabbitai]

Warning

Review limit reached

Next included review available in 3 minutes.

View limit details

Limit details: You’ve used the included review currently available. Your 91 included PR review attempts over the past 7 days set your current allowance at 1 review per hour.

Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: b2a34685-e250-45a0-8518-982cef2fbdb8

📥 Commits

Reviewing files that changed from the base of the PR and between ae89f11 and 19394c7.

📒 Files selected for processing (1)

• .github/workflows/pr-agent.yml

---

_{Comment @coderabbitai help to get the list of available commands.}

[qodo-code-review]

PR Summary by Qodo

Fix pr-agent workflow concurrency key collisions across events and PR vs issue

🐞 Bug fix ⚙️ Configuration changes 🕐 Less than 10 minutes

AI Description

• Prevent pr-agent runs from cancelling unrelated runs due to shared concurrency keys.
• Add event and PR/issue-kind discriminators to the concurrency group expression.
• Document why workflow-level concurrency requires both discriminators.

Diagram

graph TD
  A{{"GitHub event"}} --> B["pr-agent.yml workflow"] --> C(("Concurrency group")) --> D["PR review run"]
  A --> B --> C --> E["Issue/PR comment run"]
  C --> F{"Cancel in progress"}
  subgraph Legend
    direction LR
    _ext{{"External"}} ~~~ _wf["Workflow"] ~~~ _grp(("Group")) ~~~ _dec{"Decision"}
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Disable cancel-in-progress (queue instead)

• ➕ Eliminates accidental cancellations from key collisions entirely
• ➕ Simpler configuration (no complex key logic)
• ➖ Allows multiple expensive pr-agent runs to pile up and waste CI capacity
• ➖ Slower feedback for the latest PR state (older runs continue)

2. Split into separate workflows per trigger type

• ➕ Natural separation of concurrency per workflow (no cross-event collisions)
• ➕ Simplifies keys inside each workflow
• ➖ More workflow files to maintain and keep consistent
• ➖ Harder to reuse shared logic and keep permissions/inputs aligned

3. Key by stable object IDs (e.g., pull_request.node_id when present)

• ➕ Avoids reliance on shared issue/PR number sequence
• ➕ Potentially more robust for cross-repo/fork edge cases
• ➖ Not uniformly available across all event payloads (especially pure issue events)
• ➖ Still needs event-type discrimination for mixed triggers

Recommendation: Keep the PR’s approach: include both github.event_name and a PR-vs-issue discriminator in the concurrency group. It minimally changes behavior while directly addressing the two observed collision modes (cross-event cancellations and PR/issue number collisions) without increasing workflow sprawl or sacrificing cancel-in-progress efficiency.

Files changed (1) +11 / -1

Bug fix (1) +11 / -1

pr-agent.ymlDisambiguate concurrency group by event and PR-vs-issue kind +11/-1

Disambiguate concurrency group by event and PR-vs-issue kind

• Expands the concurrency group key to include 'github.event_name' and a PR/issue-kind discriminator, preventing cancellations between different event types and between PRs and issues sharing the same number. Adds detailed inline documentation explaining why workflow-level concurrency requires these discriminators and cites fleet-wide impact.

.github/workflows/pr-agent.yml

[macroscopeapp]

Approvability

Verdict: Would Approve

Macroscope's review found this PR approvable — This narrowly scoped CI fix only refines pr-agent cancellation groups so unrelated pull-request and issue events no longer cancel each other. It leaves production code, deployment behavior, permissions, triggers, and the workflow body unchanged.

Not approved because:

• Credit balance exhausted. Approvability relies on correctness review in order to determine eligibility

^{Review your spending limits in Billing settings. You can add or adjust custom eligibility rules. Learn more.}

[gitar-bot]

Note

Automatic reviews are paused because your team has used its included automatic processing for this billing period (headroom scales with your seat count). You can still comment "Gitar review" to run one anytime, and automatic reviews resume on their own by September 1. Add seats for more headroom.
Learn more

Code Review ✅ Approved

Updates the PR-agent workflow concurrency group expression to isolate runs by event name and resource type, preventing unrelated runs from cancelling each other. No issues found.

Options

Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Compact

gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[yakimoto]

Closing as redundant — my error, and worth naming rather than deleting quietly.

This repo already has #24 open from the wave-pen#418 wave, on ci/adopt-inline-pr-agent, and that branch already carries the identical full concurrency key:

group: pr-agent-${{ github.event_name }}-${{ (github.event.pull_request.number || github.event.issue.pull_request) && 'pr' || 'issue' }}-${{ github.event.pull_request.number || github.event.issue.number || github.ref }}

So this PR was a duplicate that would have conflicted on the same file, and #24 is strictly better besides: it also replaces the stale pinned reusable (@150ffae2) with the current inline template, picking up the fork gate, the per-attempt duration stamps and the CONFIG__AI_TIMEOUT correction. This PR fixed only the key and would have left the stale pin in place.

How it happened: the fan-out script checked idempotence by looking for an existing PR from its own branch name, which is the wrong question. The right one is whether any open PR already modifies the target file. Ten repos in the vulnerable set had exactly that, and all ten got a duplicate before the check caught it.

Merging #24 is the action here. Nothing is lost by closing this.

Refs wave-pen#420, wave-pen#418

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. Misleading push-trigger comment 🐞 Bug ⚙ Maintainability

Description

The new comment claims a “push-triggered pull_request review”, but this workflow does not trigger
on push events, only pull_request and issue_comment. This can mislead maintainers when
reasoning about concurrency collisions and why github.event_name is part of the key.

Code

.github/workflows/pr-agent.yml[R19-22]

+#   - `event_name` keeps a push-triggered `pull_request` review from being
+#     cancelled by an `issue_comment` on the same PR.
+#   - the `pr`/`issue` kind keeps `issue_comment` on PR #30 from colliding with
+#     `issue_comment` on Issue #30, which `event_name` alone does not separate.

Relevance

●●● Strong

The comment’s trigger wording is ambiguous; clarifying it would improve workflow maintainability
with minimal change.

PR-#23

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The workflow on: section shows only pull_request and issue_comment triggers, while the added
comment explicitly mentions a push-triggered review; therefore the comment is inaccurate.

.github/workflows/pr-agent.yml[4-9]
.github/workflows/pr-agent.yml[19-22]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A newly added comment describes a “push-triggered `pull_request` review”, but the workflow’s triggers do not include `push`. This is misleading documentation attached to a non-trivial concurrency key.

## Issue Context
The workflow triggers only on `pull_request` and `issue_comment`, so the comment should refer to `pull_request` (e.g., `synchronize`) vs `issue_comment` rather than a `push` event.

## Fix Focus Areas
- .github/workflows/pr-agent.yml[15-22]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

✅ REVIEW.md

Review mode: ⚖️ Balanced: This is a runtime CI workflow change affecting concurrency cancellation behavior; although localized to one expression, it has meaningful cross-event blast radius and warrants a careful single-pass review.

Tip of the day

💡 Did you know, you can switch off images and animations for a plain-text comment

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-code-review]

Qodo Fixer

No findings are within the configured fix scope. To change which findings are fixed, adjust the setting on your Qodo configuration page.