fix(gha): automate PR review-state and stale labels#636
Conversation
📝 WalkthroughWalkthroughThe ChangesGitHub Actions workflow hardening
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
edelauna
changed the title
edelauna
requested review from
JamesRobert20,
hannesrudolph,
navedmerchant and
taltas
as code owners
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
.github/workflows/label-pr-review-state.yml (1)
11-13: 💤 Low valueConsider
cancel-in-progress: truefor stronger consistency guarantees.The current setting allows overlapping runs to both complete, which could cause label-state races if two runs reconcile the same PR simultaneously (e.g., one run reads labels, another updates them, first run overwrites based on stale read).
Setting
cancel-in-progress: truewould prevent this race at the cost of potentially leaving some PRs unprocessed if a run is cancelled mid-flight. Given that this is hourly reconciliation and labels will be corrected on the next run, the current choice is acceptable but slightly riskier.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/label-pr-review-state.yml around lines 11 - 13, In the concurrency configuration block for label-pr-review-state, change the cancel-in-progress setting from false to true to prevent potential race conditions where overlapping workflow runs could simultaneously read and update the same PR labels, causing one run to overwrite changes from another based on stale data. This ensures only one run executes at a time for this workflow.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/label-pr-review-state.yml:
- Around line 49-51: The code attempts to call .map() on pr.requested_reviewers
without checking if it exists first, which will crash if requested_reviewers is
undefined. Guard against this by adding a null/undefined check before the .map()
call in the requestedReviewers Set initialization, providing an empty array as a
fallback when pr.requested_reviewers is not defined.
- Around line 40-43: The code accesses r.user.login without first checking if
r.user is null, which will cause a null-reference error when a reviewer's
account has been deleted. Add a guard condition to check that r.user is not null
before attempting to access r.user.login in the latest.set() call. This should
be done in the loop where reviews are being iterated and the latest map is being
populated to ensure null users are skipped gracefully.
- Around line 46-60: The logic for determining the PR label state only considers
individual requested reviewers from pr.requested_reviewers but does not account
for team review requests, which are retrieved via a separate GitHub API
endpoint. When a team is requested to review and one of its members submits a
changes-requested review, the workflow cannot match the team member to the team
request, causing incorrect label assignment. Add a separate API call to fetch
team review requests (teams are returned separately from individual users), then
expand the requestedReviewers set to include both individual user logins and the
logins of all members within requested teams. This ensures that when
changeRequestReviewers are checked against requestedReviewers using the every()
method, team members are properly recognized as part of a requested team review.
---
Nitpick comments:
In @.github/workflows/label-pr-review-state.yml:
- Around line 11-13: In the concurrency configuration block for
label-pr-review-state, change the cancel-in-progress setting from false to true
to prevent potential race conditions where overlapping workflow runs could
simultaneously read and update the same PR labels, causing one run to overwrite
changes from another based on stale data. This ensures only one run executes at
a time for this workflow.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: d181b2d5-d2c8-4dfd-a1c1-3c634dd13f3f
📒 Files selected for processing (2)
.github/workflows/label-pr-review-state.yml.github/workflows/stale.yml
| for (const r of reviews) { | ||
| if (r.state !== 'COMMENTED') { | ||
| latest.set(r.user.login, r); | ||
| } |
There was a problem hiding this comment.
Guard against deleted reviewer accounts.
If a reviewer's account has been deleted, r.user may be null, causing a null-reference error on r.user.login. This would fail the reconciliation for that PR.
🛡️ Proposed fix to handle null user
for (const r of reviews) {
- if (r.state !== 'COMMENTED') {
+ if (r.state !== 'COMMENTED' && r.user) {
latest.set(r.user.login, r);
}
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| for (const r of reviews) { | |
| if (r.state !== 'COMMENTED') { | |
| latest.set(r.user.login, r); | |
| } | |
| for (const r of reviews) { | |
| if (r.state !== 'COMMENTED' && r.user) { | |
| latest.set(r.user.login, r); | |
| } | |
| } |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/label-pr-review-state.yml around lines 40 - 43, The code
accesses r.user.login without first checking if r.user is null, which will cause
a null-reference error when a reviewer's account has been deleted. Add a guard
condition to check that r.user is not null before attempting to access
r.user.login in the latest.set() call. This should be done in the loop where
reviews are being iterated and the latest map is being populated to ensure null
users are skipped gracefully.
| const changeRequestReviewers = [...latest.entries()] | ||
| .filter(([, review]) => review.state === 'CHANGES_REQUESTED') | ||
| .map(([login]) => login); | ||
| const requestedReviewers = new Set( | ||
| pr.requested_reviewers.map(reviewer => reviewer.login), | ||
| ); | ||
|
|
||
| let desiredLabel = null; | ||
| if (changeRequestReviewers.length > 0) { | ||
| desiredLabel = changeRequestReviewers.every( | ||
| reviewer => requestedReviewers.has(reviewer), | ||
| ) | ||
| ? 'awaiting-review' | ||
| : 'awaiting-author'; | ||
| } | ||
| let desiredLabel = null; | ||
| if (changeRequestReviewers.length > 0) { | ||
| desiredLabel = changeRequestReviewers.every( | ||
| reviewer => requestedReviewers.has(reviewer), | ||
| ) | ||
| ? 'awaiting-review' | ||
| : 'awaiting-author'; | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Check if any open PRs have requested_teams to understand the impact
gh pr list --state open --json number,requestedReviewers,reviews --limit 100 | \
jq '.[] | select(.requestedReviewers != null) | select(.requestedReviewers | length > 0) | {number, requestedReviewers}'Repository: Zoo-Code-Org/Zoo-Code
Length of output: 745
🏁 Script executed:
cat -n .github/workflows/label-pr-review-state.ymlRepository: Zoo-Code-Org/Zoo-Code
Length of output: 4121
🌐 Web query:
GitHub API PR requested_teams field structure how to access team review requests
💡 Result:
To access team review requests for a GitHub Pull Request via the REST API, you should use the dedicated review requests endpoint rather than relying solely on the primary Pull Request object [1][2]. Accessing Team Review Requests: The primary Pull Request object (returned by GET /repos/{owner}/{repo}/pulls/{pull_number}) does not include a detailed list of requested teams in its response body. To retrieve this information, you must call the "Get all requested reviewers for a pull request" endpoint [2][3]: GET /repos/{owner}/{repo}/pulls/{pull_number}/requested_reviewers This endpoint returns a JSON object containing two distinct arrays [2][4]: 1. users: A list of individual users whose review has been requested [2][4]. 2. teams: A list of teams whose review has been requested [2][4]. The team objects within the teams array follow the standard Team structure, which includes the following key fields: - id: The unique identifier for the team [1][2]. - slug: The URL-friendly name of the team [1][2]. - name: The display name of the team [1][2]. - url/html_url: Links to the team's resource [1][2]. - description: A description of the team [1][2]. Library Implementations: If you are using common GitHub API client libraries, they often provide helper methods to abstract this call: - PyGithub: Use the pull_request.get_review_requests method, which returns a tuple containing two PaginatedLists: one for users and one for teams [5][6]. - github3.py: Access the requested_teams attribute on the PullRequest object (which may trigger a call to the review requests endpoint) [7][8]. - Octokit.net: The PullRequest model typically includes a RequestedTeams property that maps the API response to a collection of Team objects [9]. When requesting new reviews, use the corresponding POST endpoint [2][3]: POST /repos/{owner}/{repo}/pulls/{pull_number}/requested_reviewers Provide the team_reviewers parameter as an array of team slugs to request reviews from specific teams [2][3].
Citations:
- 1: https://docs.github.com/en/rest/pulls/review-requests
- 2: https://docs.github.com/en/rest/pulls/review-requests?apiVersion=2026-03-10
- 3: https://docs.github.com/en/enterprise-server@3.10/rest/pulls/review-requests
- 4: https://share.apidog.com/apidoc/docs-site/347364/api-3489538
- 5: https://pygithub.readthedocs.io/en/latest/github_objects/PullRequest.html
- 6: https://pygithub.readthedocs.io/en/stable/github_objects/PullRequest.html
- 7: https://github3.readthedocs.io/en/3.1.0/api-reference/pulls.html
- 8: https://github3.readthedocs.io/en/stable/api-reference/pulls.html
- 9: https://github.com/octokit/octokit.net/blob/master/Octokit/Models/Response/PullRequest.cs
Team review requests are not handled.
The logic only checks pr.requested_reviewers (individual users) from the main PR object, but team review requests require a separate API call. GitHub's /requested_reviewers endpoint returns both users and teams, but the workflow doesn't call it. If a team is requested to review and one of its members submits a "changes requested" review, the workflow can't match the team to update the label correctly.
To fix this, call the additional requested_reviewers endpoint to retrieve both users and teams:
📋 Proposed fix to include team reviewers
const reviews = await github.paginate(github.rest.pulls.listReviews, {
owner, repo, pull_number: pr.number, per_page: 100,
});
+ const reviewRequests = await github.rest.pulls.requestedReviewers({
+ owner, repo, pull_number: pr.number,
+ });
+
// Reviews are returned chronologically, so later entries replace
// each reviewer's earlier decision.
const latest = new Map();
for (const r of reviews) {
if (r.state !== 'COMMENTED') {
latest.set(r.user.login, r);
}
}
const changeRequestReviewers = [...latest.entries()]
.filter(([, review]) => review.state === 'CHANGES_REQUESTED')
.map(([login]) => login);
const requestedReviewers = new Set(
- pr.requested_reviewers.map(reviewer => reviewer.login),
+ [
+ ...reviewRequests.users.map(u => u.login),
+ ...reviewRequests.teams.map(t => t.slug),
+ ],
);This requires additional logic to handle the fact that team members submit reviews individually but team requests are at the team level—consider mapping individual team member logins to their team slugs or adding team members as re-requestable reviewers directly.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/label-pr-review-state.yml around lines 46 - 60, The logic
for determining the PR label state only considers individual requested reviewers
from pr.requested_reviewers but does not account for team review requests, which
are retrieved via a separate GitHub API endpoint. When a team is requested to
review and one of its members submits a changes-requested review, the workflow
cannot match the team member to the team request, causing incorrect label
assignment. Add a separate API call to fetch team review requests (teams are
returned separately from individual users), then expand the requestedReviewers
set to include both individual user logins and the logins of all members within
requested teams. This ensures that when changeRequestReviewers are checked
against requestedReviewers using the every() method, team members are properly
recognized as part of a requested team review.
| const requestedReviewers = new Set( | ||
| pr.requested_reviewers.map(reviewer => reviewer.login), | ||
| ); |
There was a problem hiding this comment.
Guard against undefined requested_reviewers.
The pr.requested_reviewers field might be undefined in some edge cases, causing a crash on .map(...).
🛡️ Proposed fix to handle undefined requested_reviewers
const requestedReviewers = new Set(
- pr.requested_reviewers.map(reviewer => reviewer.login),
+ (pr.requested_reviewers || []).map(reviewer => reviewer.login),
);🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/label-pr-review-state.yml around lines 49 - 51, The code
attempts to call .map() on pr.requested_reviewers without checking if it exists
first, which will crash if requested_reviewers is undefined. Guard against this
by adding a null/undefined check before the .map() call in the
requestedReviewers Set initialization, providing an empty array as a fallback
when pr.requested_reviewers is not defined.
2 participants
Description
Automates pull-request review-state labels and aligns stale handling with who is expected to act next.
awaiting-authorwhile requested changes remain unresolved.awaiting-reviewafter all change-requesting reviewers are re-requested.stale-inactiveandstale-awaiting-authorlabels so the 60-day and 14-day policies cannot interfere.Security Model
The reconciliation runs only on a schedule or manual dispatch, so it executes workflow code from the trusted branch rather than code from a contributor fork. It does not check out or execute PR contents. The token is scoped to
pull-requests: writefor review reads and label mutations.Test Procedure
awaiting-author.Notes
actions/stale@v9currently emits GitHub’s Node.js 20 deprecation warning. No newer release is available; GitHub will run JavaScript actions with Node.js 24 by default starting June 16, 2026.Checklist
Summary by CodeRabbit