Skip to content

ci: adopt the inline pr-agent lane — a public repo cannot call a private reusable workflow - #50

Open
yakimoto wants to merge 6 commits into
mainfrom
ci/adopt-inline-pr-agent
Open

ci: adopt the inline pr-agent lane — a public repo cannot call a private reusable workflow#50
yakimoto wants to merge 6 commits into
mainfrom
ci/adopt-inline-pr-agent

Conversation

@yakimoto

@yakimoto yakimoto commented Aug 23, 2026

Copy link
Copy Markdown
Contributor

User description

User description

User description

Part of the fan-out tracked in wave-pen#388, proven first on wave-certify#44 where pr_agent returned success.

The defect

pr-agent.yml here calls wave-av/wave-foundation/.github/workflows/reusable-pr-agent.yml@main, and wave-foundation is private. GitHub does not permit a public repository to call a reusable workflow from a private one, so the uses: never resolves: the run dies before any job is created — conclusion: failure, total_count: 0, no log, and no check run on the head sha at all.

That is worse than a normal failure. There is nothing to click through to. Every PR on this repo has been carrying a red check that reports nothing, and external contributors see it.

Measured on this repo today — the last 5 pr-agent runs:

failure, failure, failure, failure, failure

Measured across the org on 2026-08-22: 7 public repos / 176 runs / 100% failure; 9 private repos / zero failures. A clean 16/16 split on visibility alone. Three competing hypotheses were each tested and refuted — missing OPENAI_KEY (present in both populations), a dead pinned ref (150ffae2 resolves, file exists at it), and @main vs a pinned sha (wave-realtime-edge pins @main and fails, wave-pen pins @main and works).

The fix already existed and was never adopted

wave-foundation-public/.github/workflows/pr-agent.yml is an inline copy of the same lane with no reference to the private repo. Its own header says it was written for exactly this. This PR adopts it verbatim.

So this is an adoption gap, not a design gap.

Why now, and not when #388 was filed

#388 named two blockers, and both are cleared as of wave-foundation-public#71:

  1. The shared concurrency key. The template carried pr-agent-${{ github.event.pull_request.number || … }}, shared between pull_request and issue_comment, so any bot comment cancelled a live review ~10s in (wave-pen#386). It now keys on github.event_name.
  2. Missing step-level timeouts. The template now carries 6.

Fanning out before those landed would have traded a red-with-no-log lane for a cancelled-on-every-comment lane — a different failure, not a fix.

Verified before opening this

  • The template is genuinely self-contained. Its only two wave-foundation/ mentions are in comments, not in a uses:. Checked rather than assumed, since that is the whole property this depends on.
  • The job id stays pr_agent. A job's id is its check-run context and branch protection matches on (context, app_id), so nothing needs touching on the protection side.
  • The workflow parses, and the source was read from a fresh clone of wave-foundation-public's default branch — not from a local checkout that might be parked on another branch.

The receipt is this PR, not the diff

A red lane and a working lane are indistinguishable until one actually runs — that is the whole reason 176 failures went unexamined. So the proof is pr-agent going green on this PR. If it does, the remaining 27 repos get the same change with evidence behind it. If it does not, we learn that here, on one low-traffic repo, instead of across the org's entire public surface.

Proven before fanning out. wave-certify#44 took this exact change first and its pr_agent run returned success on the pull_request event — a job with a real log, where the broken form produced no job at all. The other repos were not changed on hope.

Refs wave-pen#388

View with [code]smith Autofix with [code]smith
Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.


Note

Medium Risk
CI-only, but the job holds OPENAI_KEY and PR write access; fork gating and concurrency changes affect who can trigger paid reviews. Not product auth or data-path code.

Overview
Makes the advisory pr-agent check actually run on this public repo. GitHub cannot call a private reusable workflow from a public one, so the old uses: never created a job.

The workflow is now an inline copy of the foundation lane: event- and PR/issue-keyed concurrency so comments no longer cancel in-flight reviews, a fail-closed fork gate on / commands, per-attempt 6-minute timeouts with a 300s AI budget, one retry after 45s, and a verdict step that classifies timeout/cancel/429 as neutral so a flaked reviewer cannot block the PR. Maintainer /review on fork PRs is now declined rather than billed.

Reviewed by Cursor Bugbot for commit 3777f5e. Bugbot is set up for automated code reviews on this repo. Configure here.

Review in cubic

Summary by Sourcery

Adopt a self-contained, guarded pr-agent workflow so public-repository reviews execute reliably without blocking pull requests when the advisory reviewer fails.

Bug Fixes:

  • Make the advisory pr-agent check run in this public repository by replacing the inaccessible private reusable workflow with an inline lane.
  • Prevent fork-originated reviews from receiving the AI key, including fail-closed validation for slash-command comments.
  • Keep the advisory check from blocking pull requests when reviewer attempts time out, are cancelled, or encounter upstream failures.

Enhancements:

  • Separate pull request and issue-comment concurrency lanes to prevent unrelated comments from cancelling active reviews.
  • Add bounded retry handling and clearer classification of reviewer failures, cancellations, and timeouts.

PR Type

Bug fix


Description

  • Replaced private workflow reference with inline PR agent configuration

  • Fixed concurrency handling for pull_request and issue_comment events

  • Added fork detection and safety checks for public repositories

  • Improved timeout management and retry logic for AI agent

  • Enhanced verdict classification for different failure scenarios


Diagram Walkthrough

flowchart LR
  A["pr-agent.yml"] --> B["Concurrency group logic"]
  A --> C["Fork detection step"]
  A --> D["Timeout & retry handling"]
  A --> E["Verdict classification"]
Loading

File Walkthrough

Relevant files
Bug fix
pr-agent.yml
Inline PR agent workflow with enhanced safety and reliability

.github/workflows/pr-agent.yml

  • Added inline workflow configuration to avoid private repo restrictions
  • Implemented concurrency group logic that includes event type and
    PR/issue context
  • Introduced fork detection step using GitHub API to prevent execution
    on forks
  • Added detailed timeout management with per-attempt budgeting
  • Enhanced verdict classification to distinguish between different
    failure types
+325/-6 
Documentation
CHANGELOG.md
Updated changelog with PR agent workflow fixes                     

CHANGELOG.md

  • Documented fixes for PR agent workflow including fork handling
  • Added details about AI timeout adjustments
  • Recorded improvements in retry logic and verdict classification
+26/-0   

@codeant-ai

codeant-ai Bot commented Aug 23, 2026

Copy link
Copy Markdown

🤖 CodeAnt AI — Review Status

Status Commit Started (UTC) Finished (UTC)
✅ Incremental review completed b85a5fc Aug 24, 2026 · 14:37 14:37
✅ Incremental review completed b331b79 Aug 24, 2026 · 13:36 13:36
✅ Reviewed your PR 4669430 Aug 23, 2026 · 22:33 22:34

@cursor

cursor Bot commented Aug 23, 2026

Copy link
Copy Markdown

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_ed08d7fc-f157-4ecb-a88c-64b75facbe3a)

@sourcery-ai

sourcery-ai Bot commented Aug 23, 2026

Copy link
Copy Markdown

Reviewer's Guide

Replaces the broken reusable pr-agent workflow invocation with an inline, self-contained workflow tailored for public repos, adding concurrency-key fix, step-level timeouts, retry/backoff, and a non-blocking verdict step while preserving the job id and PR-agent configuration.

Sequence diagram for the inline PR-Agent review with retry and verdict

sequenceDiagram
    participant GitHub
    participant Workflow as InlineWorkflow
    participant Agent as PRAgent
    participant Router as LLMRouter

    GitHub->>Workflow: Start pr_agent for pull_request or issue_comment
    Workflow->>Agent: Run review attempt 1
    Agent->>Router: Request review
    Router-->>Agent: Result or error
    alt attempt 1 succeeds
        Agent-->>Workflow: success
    else attempt 1 fails
        Workflow->>Workflow: backoff before retry
        Workflow->>Agent: Run review attempt 2
        Agent->>Router: Request review
        Router-->>Agent: Result or error
        Agent-->>Workflow: success or failure
    end
    Workflow->>Workflow: verdict (classify, never block)
    Workflow-->>GitHub: Advisory result, workflow faults remain visible
Loading

State diagram for PR-Agent outcome classification

stateDiagram-v2
    [*] --> Attempt1
    Attempt1 --> Success: success
    Attempt1 --> Retry: failure
    Attempt1 --> Cancelled: cancelled
    Retry --> Success: retry succeeds
    Retry --> AdvisoryFailure: retry fails
    Retry --> Cancelled: cancelled
    Attempt1 --> WorkflowFault: outcome unavailable
    Success --> [*]
    AdvisoryFailure --> [*]
    Cancelled --> [*]
    WorkflowFault --> [*]
Loading

Flow diagram for public PR-Agent event isolation

flowchart TD
    Event[PR event] --> Key[pr-agent-event-name-PR-number]
    Comment[Slash-command comment] --> KeyComment[pr-agent-issue_comment-PR-number]
    Key --> Review[Run pull-request review]
    KeyComment --> Command[Run trusted slash-command review]
    Review --> Supersede[New event of same type supersedes older run]
    Command --> Separate[Comment run does not cancel push review]
Loading

File-Level Changes

Change Details Files
Replace the reusable pr-agent workflow call with an inline, self-contained workflow suitable for public repositories, including concurrency, timeout, retry, and verdict logic.
  • Inline the PR-Agent job instead of using the private wave-foundation reusable workflow, keeping the job id and OSS Qodo Merge configuration.
  • Adjust the concurrency group key to include the GitHub event name to avoid issue_comment runs cancelling pull_request reviews.
  • Add a job-level timeout and step-level timeouts for PR-Agent runs and retries to distinguish hangs from normal failures and keep attempts within the job budget.
  • Introduce a guarded job if-condition to control slash-command and pull_request triggers and avoid untrusted/forked execution.
  • Add a retry with backoff on PR-Agent failures, duplicating env configuration for both attempts.
  • Add a final verdict step that classifies outcomes (success, never-ran, cancelled, timed-out, other failure) and renders advisory failures as neutral/non-blocking.
.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

@coderabbitai

coderabbitai Bot commented Aug 23, 2026

Copy link
Copy Markdown

Warning

Review limit reached

Next included review available in 27 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: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: be74479e-89c1-442f-96e8-4ff1a22b3766

📥 Commits

Reviewing files that changed from the base of the PR and between 336db32 and 3777f5e.

📒 Files selected for processing (2)
  • .github/workflows/pr-agent.yml
  • CHANGELOG.md

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

@codeant-ai codeant-ai Bot added the size:L This PR changes 100-499 lines, ignoring generated files label Aug 23, 2026
@qodo-code-review

Copy link
Copy Markdown

PR Summary by Qodo

Fix pr-agent workflow for public repos by inlining lane (no private reusable workflow)

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

Grey Divider

AI Description

• Inline the pr-agent workflow to avoid calling a private reusable workflow from a public repo.
• Add event-scoped concurrency to prevent issue comments cancelling in-flight PR reviews.
• Add per-step timeouts, retry/backoff, and a non-blocking verdict to avoid advisory failures.
Diagram

graph TD
  E["PR / comment event"] --> C["Concurrency group"] --> J["Job: pr_agent"] --> G{"Eligible trigger?"} --> A1["PR-Agent action"] --> R{"Attempt 1 failed?"} --> A2["Retry + backoff"] --> V["Verdict (neutralize)"]
  R -- "no" --> V
  A1 -- "success" --> V
Loading
High-Level Assessment

The following are alternative approaches to this PR:

1. Call a public reusable workflow (wave-foundation-public) instead of inlining
  • ➕ Restores a single source of truth; reduces mirror drift across repos
  • ➕ Easier organization-wide updates (pin/action updates in one place)
  • ➖ Requires creating/maintaining a public reusable-workflow entrypoint and versioning strategy
  • ➖ Still needs rollout work to update callers and ensure permissions/secrets align
2. Package the lane as a composite action
  • ➕ Re-usable across public repos without workflow_call restrictions
  • ➕ Encapsulates retry/verdict logic behind a stable interface
  • ➖ Harder to express some workflow-level constructs (permissions/concurrency/triggers remain in callers)
  • ➖ More upfront refactoring and ongoing maintenance
3. Keep current reusable workflow but make the source repo public
  • ➕ Minimal caller complexity; preserves current workflow_call structure
  • ➖ Often not feasible due to repo visibility constraints and internal content exposure
  • ➖ Does not address mirror drift if public/private split remains

Recommendation: The inline adoption in this PR is the fastest correct fix for the hard GitHub constraint (public repos cannot workflow_call private repos) and immediately restores a real check-run with logs. Longer-term, consider promoting the lane into a public reusable workflow in wave-foundation-public (or a composite action) to reduce the ongoing risk of mirror drift, while keeping this inline copy as a fallback/template.

Files changed (1) +166 / -6

Other (1) +166 / -6
pr-agent.ymlInline pr-agent lane with safe concurrency, retry, and non-blocking verdict +166/-6

Inline pr-agent lane with safe concurrency, retry, and non-blocking verdict

• Replaces the private reusable-workflow call with a self-contained pr_agent job suitable for public repositories. Adds event-scoped concurrency, stricter trigger/eligibility guards, step-level timeouts, a retry with backoff, and a verdict step that classifies failures and keeps this advisory lane from blocking merges.

.github/workflows/pr-agent.yml

@macroscopeapp

macroscopeapp Bot commented Aug 23, 2026

Copy link
Copy Markdown

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This replaces a failed reusable-workflow reference with a substantial secret-bearing GitHub Actions lane that changes review execution, fork handling, retries, concurrency, and committable suggestions. The workflow’s permission model and reported status behavior need human validation before merging.

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.

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - I've reviewed your changes and they look great!

Sourcery assessment

Needs a human reviewer. If the workflow logic or trust checks are wrong, an unauthorized or unintended PR event could use the write-scoped GitHub token and OPENAI key to run the reviewer, post changes, or send repository content to the external model service. Reverting stops future runs, but any comments, commits, or exposed data produced before the revert would require separate cleanup.


Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Comment thread .github/workflows/pr-agent.yml Outdated
Comment thread .github/workflows/pr-agent.yml
@gitar-bot

gitar-bot Bot commented Aug 23, 2026

Copy link
Copy Markdown

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 2 resolved / 2 findings

Adopts an inline PR-Agent workflow for public repositories to replace the inaccessible private reusable workflow. Consider re-stamping AGENT_START before retry attempts to prevent elapsed-time double-counting, and verify whether actions/checkout is needed for the PR review action.

✅ 2 resolved
Quality: No actions/checkout before invoking The-PR-Agent/pr-agent action

📄 .github/workflows/pr-agent.yml:70-84
The job never runs actions/checkout, so if The-PR-Agent/pr-agent needs a local working copy of the repo (rather than operating purely via the GitHub API), the review step could silently fail to find diff content or crash. Since this mirrors the previously-working reusable workflow, confirm the reusable wave-foundation lane also omitted checkout before assuming this is safe, or add an explicit actions/checkout step if the action documents needing one.

Bug: Elapsed-time timeout discriminator double-counts across both attempts

📄 .github/workflows/pr-agent.yml:75-76 📄 .github/workflows/pr-agent.yml:121-124 📄 .github/workflows/pr-agent.yml:177-181
AGENT_START is stamped once before attempt 1 and never re-stamped before attempt 2, so the verdict step's ELAPSED computation is attempt1_duration + 45s backoff + attempt2_duration, not the duration of whichever single attempt ran long. If both attempts fail fast with real (non-timeout) errors but their combined time plus the 45s backoff reaches 360s (e.g., 200s + 45s + 200s = 445s), the verdict step will wrongly log pr-agent TIMED OUT instead of failed after 2 attempts ... rate-limit. This doesn't change the exit code (both branches exit 0), but it does mislead whoever reads the log to diagnose the failure — consider re-stamping AGENT_START immediately before attempt 2 (e.g. a second stamp step gated on steps.agent.outcome == 'failure') and comparing each attempt's own elapsed time independently.

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

@github-actions

Copy link
Copy Markdown

PR Code Suggestions ✨

No code suggestions found for the PR.

@qodo-code-review

qodo-code-review Bot commented Aug 23, 2026

Copy link
Copy Markdown

Code Review by Qodo

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

Grey Divider


Remediation recommended

1. Commit suggestions lack permission 🐞 Bug ≡ Correctness
Description
The workflow enables committable/auto-improve behavior, but the workflow permissions only grant
contents: read, so this job cannot write commits even when configured to do so, leading to
non-functional features and/or action failures that get masked by continue-on-error. This is
especially problematic on issue_comment runs, which can target fork PRs where committing is
impossible even if you later add write permissions.
Code

.github/workflows/pr-agent.yml[R108-111]

+          github_action_config.handle_push_trigger: "true"
+          pr_code_suggestions.commitable_code_suggestions: "true"
+          pr_code_suggestions.suggestions_score_threshold: "7"
+          pr_code_suggestions.num_code_suggestions: "6"
Evidence
The PR sets committable suggestions to true, but the workflow’s declared permissions only allow
reading repository contents, which cannot support committing changes.

.github/workflows/pr-agent.yml[26-29]
.github/workflows/pr-agent.yml[95-111]

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

### Issue description
The workflow is configured to produce *committable* code suggestions / auto-improvements, but the workflow-level permissions only grant `contents: read`. As a result, any “commit/apply” capability cannot work as configured (and may cause the pr-agent step to fail with permission errors that are later neutralized by the verdict step).

### Issue Context
This is introduced by enabling `pr_code_suggestions.commitable_code_suggestions: "true"` (and related auto-improve flags) while keeping `permissions.contents: read`.

### Fix Focus Areas
- .github/workflows/pr-agent.yml[26-29]
- .github/workflows/pr-agent.yml[105-111]

### Suggested fix
Pick one consistent operating mode:
1) **If you want committable suggestions / auto-improve**:
  - Change permissions to `contents: write`.
  - Ensure commit/apply only runs when the PR head repo is the same repo (non-fork). For `issue_comment` events you may need to fetch PR metadata (via GitHub API) and gate commit/apply accordingly, or split into two jobs with different env.
2) **If you don’t want commits from pr-agent**:
  - Set `pr_code_suggestions.commitable_code_suggestions: "false"` and consider disabling `github_action_config.auto_improve` so the configuration matches `contents: read`.

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


2. Neutral message but success exit 🐞 Bug ◔ Observability
Description
The verdict step repeatedly claims it is “Rendering NEUTRAL” but exits 0, which GitHub will record
as a successful check run; this mismatch can mislead readers/operators and undermines the intent of
communicating a non-blocking advisory outcome. If branch protection relies on status semantics, the
wording is materially inaccurate.
Code

.github/workflows/pr-agent.yml[R179-182]

+            echo "::warning::pr-agent TIMED OUT — ${ELAPSED}s against a ${STEP_BUDGET_S}s per-attempt budget, so an attempt was killed by its step timeout rather than returning an error. A hang, NOT a rate limit. Rendering NEUTRAL: an advisory reviewer must not block the PR (#3128)."
+            exit 0
+          fi
+          echo "::warning::pr-agent failed after 2 attempts (45s backoff, ${ELAPSED}s total — well inside the ${STEP_BUDGET_S}s budget, so it returned an error rather than hanging) — most commonly an upstream 429/rate-limit from the LLM router. Rendering NEUTRAL: an advisory reviewer must not block the PR (#3128)."
Evidence
The verdict branch logs “Rendering NEUTRAL” but then exit 0, which makes the job succeed in GitHub
Actions’ result model.

.github/workflows/pr-agent.yml[153-183]

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

### Issue description
The verdict step prints messages like “Rendering NEUTRAL” but then exits `0`, which marks the job as **success**, not neutral.

### Issue Context
This is in the `verdict (classify, never block)` bash script.

### Fix Focus Areas
- .github/workflows/pr-agent.yml[153-183]

### Suggested fix
Either:
- Update the messages to accurately say the job is being marked **success** (non-blocking), or
- If you truly need a neutral conclusion, implement a check-run/status update that sets a neutral conclusion (requires using the Checks API via `actions/github-script` or similar) and ensure permissions allow it.

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



Informational

3. Env duplication drift risk 🐞 Bug ⚙ Maintainability
Description
The pr-agent env configuration is duplicated across the primary and retry steps, so future updates
can easily diverge (different models/timeouts/flags between attempt 1 and 2) and produce
inconsistent behavior that is hard to debug. The comment warns about drift, but the current
structure still makes it likely over time.
Code

.github/workflows/pr-agent.yml[R127-130]

+        # Duplicated, not aliased: GitHub Actions does not support YAML anchors.
+        # Keep both blocks identical — a drift here silently reviews attempt 2
+        # against a different model than attempt 1.
+        env:
Evidence
The file contains two nearly identical env blocks (attempt 1 and retry) and explicitly notes drift
risk, confirming the maintainability concern is real and current.

.github/workflows/pr-agent.yml[95-112]
.github/workflows/pr-agent.yml[121-147]

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

### Issue description
The workflow duplicates a large `env:` block for attempt 1 and attempt 2. This is a high drift surface area: any future change has to be made twice and can silently diverge.

### Issue Context
GitHub Actions doesn’t support YAML anchors, but it **does** support job-level `env:`.

### Fix Focus Areas
- .github/workflows/pr-agent.yml[95-112]
- .github/workflows/pr-agent.yml[127-147]

### Suggested fix
Move the shared environment variables to `jobs.pr_agent.env:` (job-level env), and keep only truly step-specific env at the step level. This preserves identical configuration across attempts without duplication.

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


Grey Divider

Context sources
✅ REVIEW.md
Review mode: ⚖️ Balanced: This is a behavior-changing CI workflow with substantial retry, timeout, concurrency, permission, event-filter, and verdict logic; it has meaningful blast radius but is localized enough for one careful review pass.

Grey Divider

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 ↗

Grey Divider

Qodo Logo

Comment thread .github/workflows/pr-agent.yml
Comment thread .github/workflows/pr-agent.yml Outdated
@qodo-code-review

Copy link
Copy Markdown

Qodo Fixer

✅ Merged (0) · ☑ Fixed (0)

Process

  • No fixes were applied (no_fixes_applied)

…ate reusable workflow

This repo's pr-agent.yml calls
`wave-av/wave-foundation/.github/workflows/reusable-pr-agent.yml`, and
wave-foundation is PRIVATE. GitHub does not permit a PUBLIC repository to call
a reusable workflow from a private one, so the `uses:` never resolves: the run
dies before any job is created — conclusion: failure, total_count: 0, no log,
and no check run on the head sha to read. Every PR here has carried a red check
that reports nothing, and external contributors see it.

Measured across the org 2026-08-22: 7 public repos / 176 runs / 100% failure;
9 private repos / zero failures — a clean 16/16 split on visibility alone.
Three competing hypotheses (missing OPENAI_KEY, dead pinned ref, @main vs a
pinned sha) were each tested and refuted.

THE FIX already existed and was never adopted:
wave-foundation-public/.github/workflows/pr-agent.yml is an INLINE copy of the
same lane with no reference to the private repo. This adopts it verbatim.

PROVEN BEFORE FANNING OUT. wave-certify#44 took this exact change first and its
pr_agent run returned SUCCESS on the pull_request event — a job with a real log,
where the broken form produced no job at all. 27 repos were not changed on hope.

Two prerequisites named in wave-pen#388 are cleared as of
wave-foundation-public#71: the shared concurrency key that let any bot comment
cancel a live review ~10s in (wave-pen#386) now keys on github.event_name, and
the lane carries step-level timeouts.

The job id stays `pr_agent`, so the check-run context is unchanged and no
branch protection rule needs touching.

Refs wave-pen#388

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@yakimoto
yakimoto force-pushed the ci/adopt-inline-pr-agent branch from 4669430 to 2f5e2e5 Compare August 23, 2026 22:39
@cursor

cursor Bot commented Aug 23, 2026

Copy link
Copy Markdown

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_bb4f46e3-704d-4a35-9d55-7ac425a864bc)

@github-actions

Copy link
Copy Markdown

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪
🧪 No relevant tests
⚡ Recommended focus areas for review

Misclassified Verdict

ELAPSED is measured from the job-start stamp, so it covers attempt 1 + the 45s backoff + attempt 2, but it is compared against the per-attempt budget (STEP_BUDGET_S=360). Two attempts that each return a real error after ~3 minutes total ~6.75 minutes, which trips the >= 360 branch and reports "TIMED OUT / a hang, NOT a rate limit" for what was actually an upstream error — the exact confidently-wrong cause the comment above it warns against. Stamping the start of each attempt (or comparing against 2*budget + backoff) would classify correctly.

ELAPSED=$(( $(date +%s) - ${AGENT_START:-$(date +%s)} ))
if [ "$ELAPSED" -ge "$STEP_BUDGET_S" ]; then
  echo "::warning::pr-agent TIMED OUT — ${ELAPSED}s against a ${STEP_BUDGET_S}s per-attempt budget, so an attempt was killed by its step timeout rather than returning an error. A hang, NOT a rate limit. Rendering NEUTRAL: an advisory reviewer must not block the PR (#3128)."
  exit 0
fi
echo "::warning::pr-agent failed after 2 attempts (45s backoff, ${ELAPSED}s total — well inside the ${STEP_BUDGET_S}s budget, so it returned an error rather than hanging) — most commonly an upstream 429/rate-limit from the LLM router. Rendering NEUTRAL: an advisory reviewer must not block the PR (#3128)."
Duplicate PR Comments On Retry

The retry fires whenever attempt 1's outcome is failure, including the case where attempt 1 already posted the review and then failed later (e.g. auto_improve hitting a 429 after auto_review succeeded). Attempt 2 runs the same auto_review + auto_improve + committable-suggestions config from scratch, so the P

…t classification

Picks up wave-foundation-public#72, which landed after this PR was opened.

The template this PR originally copied classified timeouts on TOTAL job time
(attempt 1 + 45s backoff + attempt 2) against STEP_BUDGET_S=360, a PER-ATTEMPT
budget. Two healthy-but-slow attempts (~180s each) were therefore reported as
"TIMED OUT ... A hang, NOT a rate limit", and the else-branch claimed the run
was "well inside the budget" from the same misused total. Found by qodo review
on wave-monitor#48 and confirmed against the file.

Now stamps each attempt separately and classifies on the LONGEST attempt, with
if: always() end stamps so an attempt killed BY its step timeout still records
one. Verified by dry-running both cases before the template landed.

Updated in place rather than as a follow-up PR because this has not merged yet
— cheaper, and it keeps the repo from ever carrying the defective version.

Refs wave-av/wave-pen#417, wave-av/wave-pen#388
@cursor

cursor Bot commented Aug 24, 2026

Copy link
Copy Markdown

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_b48ebb60-b0fc-4822-aed6-445745c7b081)

@codeant-ai codeant-ai Bot added size:L This PR changes 100-499 lines, ignoring generated files and removed size:L This PR changes 100-499 lines, ignoring generated files labels Aug 24, 2026
…s step cap

Re-syncs this PR to the hardened template before it merges, so it cannot land
carrying the two defects it was opened with (wave-pen#418, wave-foundation-public#73).

1. Fork status is now RESOLVED, not assumed. The job-level `if:` refuses forks
   on the `pull_request` arm; it structurally cannot on `issue_comment`, because
   fork status is absent from that payload — measured, with a positive control:
   `issues/<n>.pull_request` carries exactly [diff_url, html_url, merged_at,
   patch_url, url], while `pulls/<n>.head.repo.fork` answers. A `fork gate` step
   asks the pulls endpoint and FAILS CLOSED: only a literal `false` proceeds; a
   404, a revoked token, a rate limit and `.head.repo = null` all skip.

   Scope: this lane runs no `actions/checkout`, so fork code is never fetched or
   executed and no exfiltration path existed. The durable defect was the comment
   claiming "Forks skipped (no secrets there)" — true of one arm, false of the
   other, and exactly what would mislead whoever adds a checkout step later.

2. CONFIG__AI_TIMEOUT 600 -> 300, in both env blocks. 600s inside a 360s step is
   unreachable: the runner killed the step first, so pr-agent never reached its
   own timeout and never fell back to CONFIG__FALLBACK_MODELS.

3. A latent classifier bug the gate exposed: `stamp attempt 2 end` runs under
   `if: always()`, so when attempt 2 never ran the arithmetic subtracted from
   zero and reported a 1787580408-second attempt as a confident TIMED OUT. Fixed
   at the arithmetic; the verdict also gains an explicit `skipped` branch.

The job id stays `pr_agent`, so the check-run context is unchanged and no branch
protection rule needs touching.

Refs wave-pen#418, wave-pen#417, wave-pen#388

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@cursor

cursor Bot commented Aug 24, 2026

Copy link
Copy Markdown

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_80dcbec2-de2a-46d8-929e-8c96d956e162)

…ce of a true

Review of this wave found the fail-closed gate had a fail-OPEN consumer. Two
reviewers flagged it independently, on two different repos, and they were right.

    if: steps.gate.outputs.fork != 'true'      # grants when the output is EMPTY

The gate could only fail closed if it always wrote an output. It did, on every
path — so this did not fail open today, and the implicit success() on the
consumer covers a gate that errors outright. But the safety rested on an
argument rather than on the structure, and it is the very argument this change
exists to delete: absence must not read as permission.

Two independent changes, so neither carries the invariant alone:

  - the gate now assigns a shell variable that STARTS at `true` and writes ONCE
    at the end, so no future edit adding an early exit can emit nothing;
  - the consumer requires `== 'false'`, an explicit affirmative, so an empty or
    missing output skips the agent.

Also braces both sides of the A2 subtraction in the verdict step. The bare
`ATTEMPT2_START` was CORRECT — POSIX arithmetic expansion evaluates a bare name
as a variable, verified identical (180 == 180) — but a reviewer read it as a
literal token and filed it High. An expression that reads wrong on 27 repos gets
re-filed on 27 repos, so it is normalised rather than defended.

RECEIPTS. actionlint clean; zizmor clean; shellcheck clean. The gate was driven
through all six branches plus the reviewers' no-output scenario: only a literal
`false` reaches AGENT RUNS. The verdict was re-run across all six states and is
unchanged on the five that already worked.

LIVE: wave-av/api-spec merged the previous revision and its pull_request run
executed `fork gate (issue_comment only) -> success` in production, then ran the
agent — so the gate does not wrongly refuse a legitimate same-repo PR.

Upstream: wave-av/wave-foundation-public#73. Refs wave-pen#418, wave-pen#417.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@cursor

cursor Bot commented Aug 24, 2026

Copy link
Copy Markdown

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_669f1d10-32ca-4cae-9759-834caabf6fdf)

…mber space

Review found a SECOND concurrency collision, on a different axis from the one
this template already documents (wave-pen#386).

`issue_comment` fires for ISSUES as well as PRs, and GitHub draws both from ONE
number sequence. So a comment on Issue #30 and a `/review` on PR #30 entered the
same concurrency group. Concurrency is evaluated at WORKFLOW level, BEFORE the
job-level `if:` runs — so the Issue comment cancelled the PR review already in
flight, and was then skipped itself, having done nothing.

That is the identical shape as the #386 defect the block above exists to fix,
one axis over: a run that will not review taking the lane from the run that
would have. #386 separated the two EVENTS; it did not separate the two number
spaces inside one event.

    pull_request        PR 433   -> pr-agent-pull_request-pr-433
    issue_comment on PR  30      -> pr-agent-issue_comment-pr-30
    issue_comment on ISSUE 30    -> pr-agent-issue_comment-issue-30

The last two used to be one group. actionlint and zizmor clean.

Upstream: wave-av/wave-foundation-public#73. Refs wave-pen#418, wave-pen#417.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@cursor

cursor Bot commented Aug 24, 2026

Copy link
Copy Markdown

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_451ca8d2-0a0d-4866-bf94-e597a85441d3)

@codeant-ai codeant-ai Bot removed the size:L This PR changes 100-499 lines, ignoring generated files label Aug 24, 2026
@codeant-ai codeant-ai Bot added the size:L This PR changes 100-499 lines, ignoring generated files label Aug 24, 2026
A reviewer flagged the missing entry on wave-modules#41. 25 of the 28 repos in
this wave keep the same Keep-a-Changelog convention, so the entry lands in all
of them rather than only the repo whose review happened to catch it — fixing the
reported instance and leaving the class is the pattern this wave keeps undoing.

The change IS user-visible, which is why it belongs here: a maintainer's
`/review` on a fork PR is now declined with a warning instead of silently
running, so contributors on forks see different behaviour.

Refs wave-pen#418, wave-av/wave-foundation-public#73

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@cursor

cursor Bot commented Aug 24, 2026

Copy link
Copy Markdown

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_7cd2902f-4cc4-4975-ae53-b251ad4bb4d9)

@yakimoto

Copy link
Copy Markdown
Contributor Author

Review disposition — every finding on this PR, actioned or refuted with evidence

This branch has been updated. Reviews across this wave raised nine distinct findings; four were real and are fixed, three are working-as-intended, two are refuted with measurements. Nothing was silently skipped.

Source of truth for the template: wave-av/wave-foundation-public#73. Tracked as wave-pen#418.

Fixed — the reviewers were right

finding disposition
Fork gate fails openif: … != 'true' grants on an empty output Accepted. The gate wrote an output on every path, and a gate step that errors is caught by the consumer's implicit success(), so it did not fail open in practice — but the safety rested on an argument rather than the structure. The gate now writes once, from a variable that starts at the refusing value, and the consumer requires == 'false'. Two independent changes, so neither carries the invariant alone.
issue_comment has no fork check / secrets on fork PRs Accepted, and the cause is structural. Fork status is absent from an issue_comment payload — issues/<n>.pull_request carries exactly [diff_url, html_url, merged_at, patch_url, url], while pulls/<n>.head.repo.fork answers. A fork gate step now asks the pulls endpoint.
AI timeout exceeds step timeout Accepted. CONFIG__AI_TIMEOUT: "600" inside a 360s step is unreachable — the runner killed the step first, so pr-agent never fell back to CONFIG__FALLBACK_MODELS. Now 300, in both env blocks.
issue_comment concurrency collision (PR #N vs Issue #N) Accepted, and it is a genuinely separate axis from wave-pen#386. PRs and Issues share one number sequence, and concurrency is evaluated before the job if: — so a comment on Issue #30 cancelled a /review on PR #30 and then skipped itself. The key now carries a pr/issue discriminator.
Verdict ELAPSED is cumulative, not per-attempt Already fixed in wave-foundation-public#72, before this wave. Fixing the fork gate then exposed a fourth defect in the same step, see below.
Missing CHANGELOG entry Accepted — and widened. Raised on one repo; 25 of the 28 in this wave share the Keep-a-Changelog convention, so the entry landed in all 25. Fixing the reported instance and leaving the class is the pattern this wave keeps undoing.

Refuted — with the measurement, not an opinion

The-PR-Agent/pr-agent is an unverified org / possible typosquat. The best-reasoned finding here, and it inverts on checking. All three names are one repository:

$ gh api repos/qodo-ai/pr-agent   --jq .full_name    ->  The-PR-Agent/pr-agent
$ gh api repos/Codium-ai/pr-agent --jq .full_name    ->  The-PR-Agent/pr-agent
   stars=12688  created=2023-07-05  fork=false  parent=none
   description: "PR Agent: The Original Open-Source PR Reviewer. This project is not the Qodo free tier."

GitHub is following an org rename (Codium-ai → qodo-ai → The-PR-Agent) transparently. fork: false with no parent rules out a fork; 12.7k stars and a 2023 creation date rule out a fresh typosquat. The pinned SHA resolves to the same object through either name.

The suggested remedy would make things worse: qodo-ai/pr-agent is a stale name that resolves only via redirect, and a released org name can be re-registered by anyone. Pinning to the current name plus a commit SHA is the stronger position. Keeping as is.

A2 arithmetic is broken — bare ATTEMPT2_START is a literal token. Not so; POSIX arithmetic expansion evaluates a bare name as a variable:

$ ATTEMPT2_END=1000 ATTEMPT2_START=820 bash -c 'echo $(( ${ATTEMPT2_END:-0} - ATTEMPT2_START ))'
180
$ ATTEMPT2_END=1000 ATTEMPT2_START=820 bash -c 'echo $(( ${ATTEMPT2_END:-0} - ${ATTEMPT2_START:-0} ))'
180

Normalised anyway. An expression that reads wrong on 27 repos gets re-filed on 27 repos, so consistency is worth more than being right about it.

Committable suggestions lack contents: write. Not reproduced. Committable suggestions are GitHub ```suggestion blocks posted through the pull-requests API — the human clicks "Commit suggestion" and GitHub commits under their identity; the workflow never pushes. pull-requests: write is granted. Checked against a live run rather than argued: api-spec run `32733642988` ran with `Contents: read` and `commitable_code_suggestions: true`, concluded success, posted 3 comments, and its log contains no permission error (the one `403` substring match is inside a docker layer digest).

Working as intended

  • No actions/checkout. Deliberate, and load-bearing: it is exactly why the fork finding is defence-in-depth rather than a live exfiltration path. Fork code is never fetched or executed.
  • A neutral message with a success exit. pr-agent is an advisory reviewer — it annotates, it never gates correctness — so a flaked reviewer must not block a PR. That is wave-foundation-public#3128's whole point.
  • A gh api rate limit treated the same as a real fork. That is the fail-closed design. "I could not tell" must not reach the same answer as "not a fork" on the arm holding OPENAI_KEY; the cost of erring this way is one skipped advisory review.

One defect no reviewer found, surfaced by fixing the first

stamp attempt 2 end runs under if: always(), so when attempt 2 never ran the verdict subtracted from zero:

::warning::pr-agent TIMED OUT — the longest attempt ran 1787580408s against a 360s per-attempt budget

A 56-year attempt, stated as a confident diagnosis. Latent since #72; the fork gate is simply the first path that reaches it. Fixed at the arithmetic, and the verdict gained an explicit skipped branch.

Receipts

actionlint clean · zizmor --persona=regular clean · shellcheck clean on both new run: blocks. The gate was driven through all six branches plus the no-output scenario — only a literal false reaches AGENT RUNS. The verdict was executed old-vs-new across six states; the five that already worked are byte-identical. Live: wave-av/api-spec merged an earlier revision and its pull_request run executed fork gate (issue_comment only) -> success in production and then ran the agent, so the gate does not wrongly refuse a legitimate same-repo PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size:L This PR changes 100-499 lines, ignoring generated files

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant