Skip to content

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

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#98
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

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, concurrency, and timeout/retry logic are security- and cost-sensitive if mis-set.

Overview
Makes the advisory pr-agent check actually run on this public repo. GitHub cannot call a private reusable workflow from a public repo, so the old uses: never started a job (red check, no log).

The workflow is now an inline copy of the foundation lane: event-keyed concurrency so comments no longer cancel in-flight push reviews, a fail-closed fork gate on / commands (API lookup, only literal false proceeds), two 6-minute attempts with a 45s backoff, and a verdict step that classifies timeout/cancel/429 as neutral so a flaked reviewer cannot block the PR. CONFIG__AI_TIMEOUT is 300s so it sits inside the step budget.

Slash-command reviews stay limited to trusted members. Fork PRs are skipped with a warning rather than billed on OPENAI_KEY. Changelog documents the three related defects.

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

Review in cubic

Summary by Sourcery

Restore the public pr-agent lane and make advisory reviews resilient without allowing workflow failures or untrusted fork events to block or compromise pull requests.

Bug Fixes:

  • Restore the public repository’s pr-agent check by replacing the inaccessible private reusable workflow with an inline workflow.
  • Prevent fork-triggered reviews from using repository secrets by adding fail-closed fork handling for pull requests and issue comments.
  • Make advisory PR-agent failures non-blocking while distinguishing successful, skipped, cancelled, timed-out, and upstream failure outcomes.

Enhancements:

  • Improve review reliability with event-specific concurrency lanes, bounded attempts, retry backoff, and aligned AI and step timeouts.

CI:

  • Update the pr-agent CI workflow to run directly in the public repository with safer concurrency, retry, timeout, and outcome handling.

Documentation:

  • Document the pr-agent workflow corrections and their fork, timeout, and verdict behavior in the changelog.

PR Type

Bug fix


Description

  • Replaced private workflow reference with inline PR agent configuration

  • Added concurrency controls for event-specific grouping

  • Implemented fork gate validation for issue_comment events

  • Added retry mechanism with timeout budgeting

  • Fixed timeout handling and error classification


Diagram Walkthrough

flowchart LR
  A[".github/workflows/pr-agent.yml"] --> B["Adopt inline workflow"]
  A --> C["Concurrency group adjustments"]
  A --> D["Fork validation step"]
  A --> E["Retry logic with timeout budget"]
  A --> F["Timeout error classification"]
Loading

File Walkthrough

Relevant files
Configuration changes
pr-agent.yml
Replaced private workflow with inline configuration and added
reliability fixes

.github/workflows/pr-agent.yml

  • Replaced workflow reference from private repo to inline configuration
  • Added event-specific concurrency grouping to prevent job collisions
  • Implemented fork validation step for issue_comment events
  • Added retry mechanism with 45s backoff between attempts
  • Fixed timeout handling and improved error classification logic
+325/-6 
Documentation
CHANGELOG.md
Updated changelog with PR agent workflow fixes                     

CHANGELOG.md

  • Documented PR agent fixes for fork handling and timeout budgeting
  • Added details about concurrency group adjustments
  • Noted improvements in error classification and retry logic
+24/-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 c198387 Aug 24, 2026 · 14:36 14:37
✅ Incremental review completed c7a9ec4 Aug 24, 2026 · 13:35 13:36
✅ Reviewed your PR 74c06d8 Aug 23, 2026 · 22:30 22:31

@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_ff496591-0b8e-4c2f-bf3a-b51d2241d839)

@sourcery-ai

sourcery-ai Bot commented Aug 23, 2026

Copy link
Copy Markdown

Reviewer's Guide

Replace the failing reusable pr-agent workflow call with an inline, self-contained workflow definition tailored for public repos, while syncing it to the current reusable lane behavior (concurrency, retries, timeouts, and non-blocking verdicts).

Sequence diagram for the inline PR-Agent review and retry flow

sequenceDiagram
    participant GitHub
    participant Workflow as pr_agent workflow
    participant Agent as PR-Agent
    participant Router as LLM router

    GitHub->>Workflow: Trigger pull_request or trusted issue_comment
    Workflow->>Agent: Run attempt 1
    Agent->>Router: Request review
    Router-->>Agent: Review result or error
    alt Attempt 1 succeeds
        Agent-->>Workflow: success
    else Attempt 1 fails
        Workflow->>Workflow: backoff before retry
        Workflow->>Agent: Run attempt 2
        Agent->>Router: Request review
        Router-->>Agent: Review result or error
    end
    Workflow->>Workflow: verdict (classify, never block)
    Workflow-->>GitHub: Success or advisory neutral outcome
Loading

File-Level Changes

Change Details Files
Inline and modernize the pr-agent GitHub Actions workflow so public repos no longer depend on a private reusable workflow and the lane behaves like the current shared template.
  • Replace the reusable workflow call with a full inline job definition that runs The-PR-Agent/pr-agent directly with the org’s OpenAI routing configuration.
  • Adjust the concurrency group key to include the GitHub event name so slash-command comment runs no longer cancel in-flight pull_request reviews.
  • Add a 15-minute job timeout and 6-minute step-level timeouts for each pr-agent attempt to distinguish hangs from normal failures and keep retries within budget.
  • Introduce a second pr-agent attempt with 45s backoff, duplicating env configuration, and allow both attempts to continue on error.
  • Add a final verdict step that classifies outcomes (success, never-ran, cancelled, timed-out, failed) and converts non-reviewer faults or upstream flakes into neutral/warning results so pr-agent never blocks merges.
  • Tighten the job if: condition to only run on trusted slash commands and qualifying pull_request events (non-bot, non-draft, non-fork).
.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 26 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: f8171687-db22-4c24-a6c3-dcca502065fd

📥 Commits

Reviewing files that changed from the base of the PR and between 19897c2 and d6d2c9d.

📒 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
@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
🔒 No security concerns identified
⚡ Recommended focus areas for review

Misclassified Timeout

ELAPSED is measured from the stamp attempt start step to the verdict step, so it covers attempt 1 + the 45s backoff + attempt 2 — not a single attempt. The comparison against STEP_BUDGET_S (360s, a per-attempt budget) therefore reports "TIMED OUT ... an attempt was killed by its step timeout" whenever the two attempts plus backoff simply exceed 360s in total, even if both attempts returned fast errors (e.g. attempt 1 fails at 200s, 45s sleep, attempt 2 fails at 200s → 445s). Given the comments' stated goal of not asserting a confidently wrong cause, the discriminator should be per-attempt elapsed time (stamp before each attempt, or compare against 2*budget + 45).

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)."
Possible Env Key Drift

The retry step's env block appears to use a different key name for the API key than attempt 1 (OPENAI_KEY in attempt 1). If the two blocks genuinely differ, attempt 2 runs without credentials and will always fail, defeating the retry that this change was added to provide. This may be a rendering/redaction artifact in the diff — worth confirming the two env blocks are byte-identical as the accompanying comment requires.

env:
  OPENAI_KEY: ${{ secrets.OPENAI_KEY }}

@macroscopeapp

macroscopeapp Bot commented Aug 23, 2026

Copy link
Copy Markdown

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — The PR replaces a non-running reusable-workflow reference with a substantial executable CI lane that uses repository secrets and pull-request write permissions while adding fork gating, retries, concurrency, and timeout logic. Its security- and cost-sensitive behavior is broader than a minor CI change and should receive human review.

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.

@qodo-code-review

Copy link
Copy Markdown

PR Summary by Qodo

CI: inline pr-agent workflow to avoid private reusable-workflow calls

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

Grey Divider

AI Description

• Replace private reusable-workflow call with an inline pr-agent job for public repos.
• Fix concurrency collisions between PR runs and slash-command comment runs.
• Add retries, per-step timeouts, and a non-blocking verdict to avoid red advisory checks.
Diagram

graph TD
  E["GitHub event: PR or comment"] --> C["Concurrency group (event-scoped)"] --> G{"Eligible trigger?"} --> A1["PR-Agent action (attempt 1)"] --> D{"Attempt failed?"}
  D -- "no" --> V["Verdict: success"] --> R["Check run result"]
  D -- "yes" --> B["Backoff + attempt 2"] --> V
Loading
High-Level Assessment

The following are alternative approaches to this PR:

1. Call a public reusable workflow instead of inlining
  • ➕ Single source of truth avoids drift across repos
  • ➕ Still avoids the private→public reusable-workflow restriction
  • ➖ Introduces a cross-repo dependency that can fail to resolve if ref/pinning is mishandled
  • ➖ Requires maintaining a stable public workflow API and versioning strategy
2. Package the lane as a composite GitHub Action
  • ➕ Centralized implementation with explicit inputs/outputs; reusable without workflow-calling constraints
  • ➕ Easier to unit-test/release as a versioned artifact
  • ➖ More upfront work to refactor workflow logic into an action
  • ➖ Some workflow-level features (permissions/concurrency) still need to live in each repo

Recommendation: Proceed with this PR’s inline adoption because it immediately fixes the worst failure mode (no jobs/logs/check run) for a public repo and adds resiliency (event-scoped concurrency, step budgets, retry + verdict). If drift becomes a recurring cost across public repos, consider migrating to a public reusable workflow (or composite action) as a follow-up to re-centralize maintenance while staying within GitHub’s visibility rules.

Files changed (1) +166 / -6

Other (1) +166 / -6
pr-agent.ymlInline pr-agent job with event-scoped concurrency, retry, and verdict +166/-6

Inline pr-agent job with event-scoped concurrency, retry, and verdict

• Replaces the private reusable-workflow 'uses:' call with a fully inline 'pr_agent' job suitable for public repos. Adds event-name-scoped concurrency, job gating for trusted slash commands and non-fork PRs, step-level timeouts, a backoff+retry attempt, and a verdict step that classifies outcomes and keeps advisory failures from blocking PRs.

.github/workflows/pr-agent.yml

@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. This replaces a private reusable workflow with a directly invoked third-party action that receives OPENAI_KEY and pull-request write permission, so a flawed trust boundary or compromised action could expose the key or alter pull requests in ways reverting the workflow would not undo. The retry, concurrency, and verdict changes mainly affect runtime behavior and are otherwise normally reversible.


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
@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 1 resolved / 1 findings

Adopts an inline PR-Agent workflow to resolve private reusable workflow access issues in public repositories. Consider adjusting the verdict step's ELAPSED calculation to measure per-attempt rather than cumulative time.

✅ 1 resolved
Bug: ELAPSED in verdict step measures cumulative time, not per-attempt

📄 .github/workflows/pr-agent.yml:76 📄 .github/workflows/pr-agent.yml:117-119 📄 .github/workflows/pr-agent.yml:177-181
AGENT_START (pr-agent.yml:76) is stamped once before attempt 1, but ELAPSED (pr-agent.yml:177) is computed at verdict time as now - AGENT_START, which sums attempt-1 duration + the 45s backoff + attempt-2 duration. If attempt 1 times out (~360s) and attempt 2 then fails fast (~5s), ELAPSED ≈ 410s, which is still ≥ STEP_BUDGET_S (360s), so the verdict misreports attempt 2's fast failure as a 'TIMED OUT' attempt (pr-agent.yml:178-181) even though it actually returned an error quickly. Since this only affects the diagnostic wording in a non-blocking warning (the step still exit 0s either way), it doesn't break the PR but will misdirect anyone debugging via the annotation; consider re-stamping AGENT_START immediately before each attempt (e.g., a per-attempt start step) or comparing against each step's own duration if available.

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

@bito-code-review

Copy link
Copy Markdown

The bug is confirmed. The ELAPSED calculation in the verdict step uses a single AGENT_START timestamp from the beginning of the job, causing it to accumulate time across multiple attempts and the backoff period. This leads to incorrect reporting when a second attempt fails quickly after a long-running first attempt.

To fix this, you should re-stamp AGENT_START immediately before each attempt. Here is the corrected workflow structure:

.github/workflows/pr-agent.yml

- name: stamp attempt start
  run: echo "AGENT_START=$(date +%s)" >> "$GITHUB_ENV"

- name: PR-Agent (OSS qodo-merge)
  id: agent
  ...

- name: backoff before retry
  if: steps.agent.outcome == 'failure'
  run: sleep 45

- name: stamp retry attempt start
  if: steps.agent.outcome == 'failure'
  run: echo "AGENT_START=$(date +%s)" >> "$GITHUB_ENV"

- name: PR-Agent retry (attempt 2)
  id: agent_retry
  ...

@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 (0) 📘 Rule violations (0) 📜 Skill insights (0)

Grey Divider


Remediation recommended

1. AI timeout exceeds step budget ✓ Resolved 🐞 Bug ☼ Reliability
Description
Each pr-agent attempt is capped by timeout-minutes: 6 (360s), but the action is configured with
CONFIG__AI_TIMEOUT: "600" (600s). This makes the configuration internally inconsistent and
increases the likelihood that attempts are killed by the step timeout rather than timing out
gracefully within the action’s own budget.
Code

.github/workflows/pr-agent.yml[R100-103]

+          OPENAI_API_BASE: "https://api.wave.online/v1/dispatch"
+          CONFIG__CUSTOM_MODEL_MAX_TOKENS: "32000"
+          CONFIG__AI_TIMEOUT: "600"
+          CONFIG__FALLBACK_MODELS: "openai/qwen3-coder:30b"
Relevance

●● Moderate

Timeout budgets are commonly accepted, but no close precedent for AI-vs-step timeout mismatch
specifically.

PR-#30

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
Both attempts have timeout-minutes: 6, while their env sets CONFIG__AI_TIMEOUT to 600 seconds,
creating a mismatch between the step-level cutoff and the action’s configured timeout.

.github/workflows/pr-agent.yml[78-103]
.github/workflows/pr-agent.yml[121-139]
.github/workflows/pr-agent.yml[156-159]

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 enforces a 6-minute step timeout per attempt but configures the pr-agent action with a 10-minute AI timeout. These competing limits make it more likely the step timeout kills the attempt mid-flight.

### Issue Context
Both attempt 1 and attempt 2 set `timeout-minutes: 6`, while their env includes `CONFIG__AI_TIMEOUT: "600"`.

### Fix Focus Areas
- .github/workflows/pr-agent.yml[78-104]
- .github/workflows/pr-agent.yml[121-139]

### Suggested fix
Either reduce `CONFIG__AI_TIMEOUT` to <= 360 (and keep the step timeout as-is) or increase the step timeout and update `STEP_BUDGET_S` and the job-level budget math/comments accordingly.

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


2. Timeout detection misclassifies runs ✓ Resolved 🐞 Bug ≡ Correctness
Description
The verdict step compares total elapsed time since the very first stamp (including the 45s backoff
and both attempts) against the per-attempt budget (360s), so long-but-valid two-attempt failures can
be incorrectly labeled “TIMED OUT”. This produces misleading diagnostics and can send responders to
the wrong root cause.
Code

.github/workflows/pr-agent.yml[R177-180]

+          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
Relevance

●● Moderate

Nuanced verdict-logic correctness issue; no close precedent found either way.

PR-#95

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
AGENT_START is stamped once before attempt 1, then the workflow may sleep 45s and run attempt 2;
the verdict uses the total elapsed against a per-attempt constant of 360s.

.github/workflows/pr-agent.yml[75-77]
.github/workflows/pr-agent.yml[117-120]
.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 logic uses `AGENT_START` stamped once before attempt 1 and then treats `ELAPSED >= STEP_BUDGET_S` as proof that an attempt was killed by the step timeout. But `ELAPSED` includes the retry backoff and attempt 2 runtime, so it can exceed 360s even when neither attempt hit the 6-minute step timeout.

### Issue Context
The workflow has two attempts and an explicit `sleep 45`. The verdict message claims the threshold is “per-attempt” while measuring a cross-attempt total.

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

### Suggested fix
Track timing per attempt (e.g., stamp `AGENT1_START`/`AGENT2_START` immediately before each attempt and compute elapsed for each separately), or if you intentionally want a single total threshold, change the comparison to something like `2*STEP_BUDGET_S + backoff + overhead` and update the messaging to match.

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



Informational

3. Fork PRs not blocked ✓ Resolved 🐞 Bug ⛨ Security
Description
The issue_comment trigger path can run PR-Agent for slash commands without checking whether the
target PR is from a fork, yet it still passes secrets.OPENAI_KEY and secrets.GITHUB_TOKEN. This
contradicts the comment “Forks skipped” and creates a secrets-exposure risk if the action ever
fetches/executes PR code or otherwise leaks env.
Code

.github/workflows/pr-agent.yml[R61-64]

+        (github.event_name == 'issue_comment'
+            && github.event.issue.pull_request
+            && startsWith(github.event.comment.body, '/')
+            && contains(fromJSON('["MEMBER","OWNER","COLLABORATOR"]'), github.event.comment.author_association))
Relevance

● Weak

A same-file, recent fork/secret guard suggestion was explicitly rejected in PR #95.

PR-#95

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The workflow explicitly enables issue_comment runs, and in that event branch the if: lacks any
fork check while still running pr-agent with secrets in the environment.

.github/workflows/pr-agent.yml[20-25]
.github/workflows/pr-agent.yml[58-69]
.github/workflows/pr-agent.yml[78-112]

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 job-level `if:` blocks forks only for the `pull_request` event, but not for `issue_comment` slash-command runs. Despite that, the workflow still injects `OPENAI_KEY`/`GITHUB_TOKEN` into the action steps.

### Issue Context
For `issue_comment` events, the payload doesn’t include `head.repo.fork`, so you can’t enforce “no forks” purely in the job `if:` using only `github.event.*` fields.

### Fix Focus Areas
- .github/workflows/pr-agent.yml[55-112]

### Suggested fix
Add an early guard step (before the pr-agent steps) that queries the PR via GitHub API (e.g., `actions/github-script`) to determine whether the PR’s head repo is a fork, and then conditionally skip the pr-agent steps when it is. Apply the same guard to both `agent` and `agent_retry` steps (and ideally also skip the `sleep 45`).

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


Grey Divider

Context sources
✅ Compliance rules (platform): 2 rules
✅ REVIEW.md
Review mode: ⚖️ Balanced: Downgraded extended -> standard: change is below the extended eligibility bar (hunks 2/18, lines 172/200; both must reach the floor). Router rationale: This is a behavior-heavy CI workflow rewrite with multiple independent paths—permissions and event gating, concurrency, retries/timeouts, duplicated action configuration, and verdict classification—where subtle defects could be easy to miss in one 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 Outdated
Comment thread .github/workflows/pr-agent.yml
…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 74c06d8 to 0991c07 Compare August 23, 2026 22:39
@qodo-code-review

Copy link
Copy Markdown

Qodo Fixer

✅ Merged (0) · ☑ Fixed (0)

Process

  • No fixes were applied (no_fixes_applied)

@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_5d44b9a0-ddd4-4333-b998-256a520fb62b)

@yakimoto
yakimoto enabled auto-merge August 24, 2026 13:21
…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_dd9cdf49-9433-4bd2-8196-497dadf8864b)

@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_f40b3dad-1966-49ad-99df-26e7f866d5eb)

…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_d52cf621-a3c2-4822-bf19-07780ac4af8a)

…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_32073538-77d0-4be9-96f8-8e9dd19735fc)

@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
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_eba3211d-24bc-4ab9-8d5e-0f41f4a5ec09)

@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

Review effort 3/5 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