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

[yakimoto]

User description

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(deps): update rubygems/configure-rubygems-credentials action to v2.1.0 #30 colliding with issue_comment on Issue chore(deps): update rubygems/configure-rubygems-credentials action to v2.1.0 #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

Low Risk
CI workflow concurrency only; no application code, auth, or data handling.

Overview
Fixes pr-agent GitHub Actions concurrency so unrelated runs no longer cancel each other when they share the same PR/issue number.

The concurrency group key is expanded from number/ref only to include github.event_name and a pr vs issue discriminator, with an inline comment explaining why both are required (workflow-level concurrency vs job if:, and PR/issue number collision). cancel-in-progress and triggers, permissions, and the reusable workflow pin are unchanged.

^{Reviewed by Cursor Bugbot for commit a317ced. Bugbot is set up for automated code reviews on this repo. Configure here.}

Summary by Sourcery

Bug Fixes:

• Prevent pr-agent workflow runs for different event types or PR/Issue targets with the same number from cancelling one another.

---

CodeAnt-AI Description

Prevent unrelated PR and issue events from cancelling each other

What Changed

• Workflow runs now use separate concurrency groups for different event types
• Pull request and issue activity with the same number no longer shares a cancellation group
• Active reviews are protected from being cancelled by unrelated comments or events

Impact

✅ Fewer cancelled pull request reviews
✅ Reliable reviews during simultaneous PR and issue activity
✅ Fewer skipped workflow runs

💡 Usage Guide

Checking Your Pull Request

Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.

Talking to CodeAnt AI

Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:

@codeant-ai ask: Your question here

This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.

Example

@codeant-ai ask: Can you suggest a safer alternative to storing this secret?

Preserve Org Learnings with CodeAnt

You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:

@codeant-ai: Your feedback here

This helps CodeAnt AI learn and adapt to your team's coding style and standards.

Example

@codeant-ai: Do not flag unused imports.

Retrigger review

Ask CodeAnt AI to review the PR again, by typing:

@codeant-ai: review

Check Your Repository Health

To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.

[codeant-ai]

🤖 CodeAnt AI — Review Status

Status	Commit	Started (UTC)	Finished (UTC)
✅ Reviewed your PR	a317ced	Aug 24, 2026 · 17:15	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_050a5224-2392-40cd-9ce7-d75e0d722ecc)

[coderabbitai]

Warning

Review limit reached

Next included review available in 2 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: 392f3fb0-bc76-48fa-a816-9a7b9adb40f8

📥 Commits

Reviewing files that changed from the base of the PR and between 2bd455f and a317ced.

📒 Files selected for processing (1)

• .github/workflows/pr-agent.yml

---

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

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Updates the pr-agent workflow’s concurrency group to distinguish both event type and PR/issue kind, preventing unrelated runs with the same number from cancelling one another while leaving triggers, permissions, job logic, and cancellation policy unchanged.

Sequence diagram for workflow-level concurrency cancellation

sequenceDiagram
    participant Review as pull_request review
    participant Comment as issue_comment
    participant Concurrency as GitHub workflow concurrency

    Review->>Concurrency: evaluate group pr-agent-pull_request-pr-N
    Comment->>Concurrency: evaluate group pr-agent-issue_comment-pr-N
    Concurrency-->>Review: keep separate run
    Concurrency-->>Comment: keep separate run

Loading

Flow diagram for discriminated pr-agent concurrency groups

flowchart LR
    PullRequest[pull_request for PR N] --> GroupPR[pr-agent-pull_request-pr-N]
    IssueCommentPR[issue_comment on PR N] --> GroupCommentPR[pr-agent-issue_comment-pr-N]
    IssueCommentIssue[issue_comment on Issue N] --> GroupCommentIssue[pr-agent-issue_comment-issue-N]
    GroupPR -. no collision .-> GroupCommentPR
    GroupCommentPR -. no collision .-> GroupCommentIssue

Loading

File-Level Changes

Change	Details	Files
Make the workflow concurrency key unique across triggering event and PR-versus-issue context.	Prefix the group with github.event_name to isolate different event types. Add a pr/issue discriminator so identical issue and pull-request numbers cannot collide. Retain the existing number-or-ref fallback and cancellation behavior. Document why both discriminators are required and cite the fleet-wide defect measurement.	.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.

[qodo-code-review]

PR Summary by Qodo

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

🐞 Bug fix ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Prevent pr-agent workflow runs from cancelling unrelated runs due to shared concurrency keys.
• Discriminate concurrency groups by GitHub event type and PR-vs-issue kind.
• Document why both discriminators are required given workflow-level concurrency evaluation.

Diagram

graph TD
  A{{"GitHub events"}} --> B["pr-agent.yml workflow"] --> C["Concurrency group key"] --> D["Workflow runs"] --> E["pr_agent job"]
  B --> F["Reusable lane / job if" ]
  subgraph Legend
    direction LR
    _ext{{"External trigger"}} ~~~ _file["Workflow file"] ~~~ _flow["Runtime behavior"]
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Disable cancel-in-progress

• ➕ Eliminates accidental cancellation due to key collisions
• ➖ Allows backlog/queue buildup; slower feedback on fast-updating PRs; defeats intended ‘latest run wins’ behavior

2. Split workflows per event type

• ➕ Naturally isolates concurrency domains by event without complex expressions
• ➖ Workflow duplication and drift risk; harder to maintain across many repos; still needs PR-vs-issue separation for issue_comment

3. Use separate concurrency keys per job (where possible)

• ➕ More granular cancellation control for specific lanes/jobs
• ➖ Does not solve the root problem here because concurrency is evaluated at workflow level before job if-conditions

Recommendation: Keep the PR’s approach: it fixes the root cause by making the workflow-level concurrency key uniquely identify (1) the triggering event type and (2) whether the number refers to a PR or an issue. This preserves cancel-in-progress semantics while preventing cross-event and PR-vs-issue collisions.

Files changed (1) +11 / -1

Bug fix (1) +11 / -1

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

Disambiguate workflow concurrency group by event and PR vs issue kind

• Adds documentation explaining why workflow-level concurrency can cancel runs before job-level 'if:' checks. Updates the 'concurrency.group' expression to include 'github.event_name' and a PR/issue discriminator to prevent collisions between different event types and between PR #N and Issue #N.

.github/workflows/pr-agent.yml

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This isolated CI change alters workflow-level cancellation and concurrency for the automated PR-agent lane, allowing event types and PR/issue targets to run independently. The modified workflow is owned by another team, so human review is appropriate despite the limited diff.

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

Expands the pr-agent concurrency group key to include event name and resource type discriminators, preventing unrelated PR and issue events from canceling 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 #65 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 #65 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 #65 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 (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require 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 available for this PR yet. Findings appear here once Qodo has reviewed the PR.