Repository navigation
fix: simplify PR_URL_OVERRIDE logic to resolve review enumeration bug - #412
Conversation
## Root Cause PR #403 was not reviewed despite the workflow running successfully. Investigation revealed that PR_URL_OVERRIDE was evaluating to an empty string for pull_request synchronize events, causing the workflow to skip enumeration entirely (or fall back to list-prs.sh and silently return no candidates). The bug occurred because: 1. The original YAML boolean expression used complex && operators within || chains: (github.event_name == 'pull_request' && github.event.pull_request.html_url) 2. For some event payloads, github.event.pull_request.html_url was null 3. OR the YAML expression evaluation has precedence/scoping issues with the && operator This caused PR_URL_OVERRIDE to fall through to the empty string default. ## Solution Simplify the expression to directly access github.event.pull_request.html_url without boolean event_name checks. This field is: - Populated for both 'pull_request' and 'pull_request_review' events - Null/falsy for other event types, which causes safe fallthrough to the next || clause - Already successfully used this way in the concurrency group logic ## Result - pull_request (synchronize, ready_for_review, reopened): PR_URL_OVERRIDE is set directly - pull_request_review (submitted, dismissed): PR_URL_OVERRIDE is set directly - check_suite: PR_URL_OVERRIDE is null, falls through to CHECK_SUITE_PRS logic - All other events: PR_URL_OVERRIDE is null, falls through to list-prs.sh Fixes #403 not being reviewed. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
|
Note Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported. |
|
Warning Review limit reached
More reviews will be available in 54 minutes and 47 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
There was a problem hiding this comment.
Pull request overview
Simplifies PR_URL_OVERRIDE computation in the PR review workflow to reliably capture the PR URL across pull_request / pull_request_review events, preventing unintended fallback to batch enumeration.
Changes:
- Replaced event-name-gated PR URL selection with a direct
github.event.pull_request.html_urlfallback. - Keeps the existing override priority order:
workflow_dispatchinput →repository_dispatchpayload → PR event context → empty string.



Problem
PR #403 and potentially other PRs were not being reviewed despite the pr-review.yml workflow running successfully. Root cause analysis identified that
PR_URL_OVERRIDEwas evaluating to an empty string for pull_request synchronize events.Root Cause
The
PR_URL_OVERRIDEenvironment variable used a complex YAML boolean expression with nested&&operators within||chains:This expression had operator precedence issues or evaluation logic that caused
github.event.pull_request.html_urlto be treated as falsy/null, resulting in PR_URL_OVERRIDE becoming an empty string. When empty, the enumerate step would fall back tolist-prs.sh, potentially missing the PR or encountering transient issues.Solution
Simplify the expression to directly access
github.event.pull_request.html_urlwithout event_name checks, matching the pattern already working successfully in the concurrency group:This works because:
pull_requestevents (ready_for_review, reopened, synchronize) havegithub.event.pull_request.html_urlpull_request_reviewevents (submitted, dismissed) havegithub.event.pull_request.html_urlcheck_suiteevents are handled separately via CHECK_SUITE_PRSworkflow_dispatchandrepository_dispatchare handled via inputsTesting
After this PR is merged, PR #403 or similar ready PRs should be properly reviewed on the next synchronize event. The enumerate step will now correctly populate PR_URL_OVERRIDE and use direct single-PR mode rather than falling back to list-prs.sh enumeration.