AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 15 Bitcoin

ci: don't double-assign reviewers, support manual assignment runs

Public commit record

What the developer wrote

Authored by Matt Corallo

90/100 · Strong
ci: don't double-assign reviewers, support manual assignment runs

The assign-reviewer workflow blindly picked a random reviewer every
time it ran, so a re-run (or any future non-opened trigger) could
request review from a second person even when someone was already on
the PR. Teach it to inspect the PR state first:

* Anyone already requested as a reviewer or who has submitted a
review is never picked. The author self-reviewing (commenting on
their own PR) doesn't count.
* On automatic runs (including re-runs), skip assignment entirely if
anyone from the REVIEWERS pool has already reviewed or been
requested; reviews from people outside the pool are ignored.

Also add a workflow_dispatch trigger taking a PR number so a reviewer
can be assigned manually. Manual runs skip the "someone is already on
it" check and always add a new (not-yet-involved) reviewer if an
eligible candidate remains.

This should let us fully emulate the old bot's second-reviewer
assignment logic fully via the action. A first reviewer can go hunt in
the actions page and trigger a second assignment (but we'll add a UI
element in the PR page above merge to trigger this in a nice UI).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This is a routine update to the project's automated reviewer-assignment workflow. It prevents the bot from accidentally adding a second random reviewer when one is already assigned, and adds a manual trigger so maintainers can request an additional reviewer on demand. There is no security-relevant change here.

Recommended action

No security action needed. Review as a normal CI/process improvement change.

Security signals we found

No strong security signals were identified.

Risk score

Why this scored 15/100

Our methodology →
Potential impact 0/30
Exploitability 0/25
Stealth signal 0/15
Affected reach 0/15
Confidence 10/10
Evidence quality 5/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.