Detect team review requests via the reviewers API - #141
Merged
Conversation
`requested_reviewers?` read `requested_teams` off `pr_json`, which GitHub strips for tokens that cannot see the organization's teams. The `dangermattic` bot is an outside collaborator on `wordpress-mobile`, so every PR whose only reviewer is a team — as `CODEOWNERS` assigns — was reported as having no reviewers. Verified against wordpress-mobile/release-toolkit#761, where a team review request is pending: `pr_json['requested_teams']` is `[]` without org visibility, while `pull_request_review_requests` returns the team either way. --- Generated with the help of Claude Code, https://claude.ai/code Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This PR updates the GithubUtils#requested_reviewers? Danger helper to correctly detect team review requests even when the GitHub token cannot see organization teams, by switching from pr_json fields to the dedicated “requested reviewers” API endpoint.
Changes:
- Update
requested_reviewers?to useGET /pulls/{n}/requested_reviewersvia Octokit (pull_request_review_requests). - Add small private helpers for PR repo/name extraction (
pr_repo_name,pr_number) and reuse them inactive_reviewers?. - Update RSpec coverage and add a changelog entry for the bug fix.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| lib/dangermattic/plugins/common/github_utils.rb | Switch requested-reviewer detection to the dedicated review-requests API and reuse shared PR identifiers. |
| spec/github_utils_spec.rb | Adjust tests to validate requested-reviewer detection with the new API source. |
| CHANGELOG.md | Document the behavioral fix for team review requests with limited-visibility tokens. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
5 tasks
iangmaia
reviewed
Aug 3, 2026
|
|
||
| private | ||
|
|
||
| def pr_repo_name |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Rationale
Reported on wordpress-mobile/release-toolkit#761: Danger warned "No reviewers have been set for this PR yet" on a PR whose
apps-infra-toolingteam review request had been pending for three minutes.requested_reviewers?readrequested_teamsoffpr_json. GitHub strips that field from the pull request payload for tokens that cannot see the organization's teams, and thedangermatticbot is an outside collaborator onwordpress-mobile, not a member. So on repos whereCODEOWNERSassigns a team and no individual, the warning fired on every PR until someone (or Copilot) actually reviewed.GET /pulls/{n}/requested_reviewersreports teams regardless of org visibility, so this switches to it.Gotchas
The old behaviour was masked in
release-toolkitbyactive_reviewers?: Copilot's automatic review made the check pass before anyone noticed the team wasn't being seen.This is not the timing race between PR creation and
CODEOWNERSassignment that was also suspected on that thread — the failing Danger run happened three minutes after the request was recorded.How to test
bundle exec rakeAgainst the live PR that surfaced this, the two sources differ exactly as described — old source empty without org visibility, new source correct either way: