mozilla / mozilla/bugbug

Show a completion status when a Review Helper re-review has no findings

Open Beginner friendly
#6,832 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
570
Forks
351
Avg merge
2d 13h
Merged PRs (30d)
65

Description

Review Helper re-reviews can complete successfully without leaving any visible indication on the Phabricator revision.

Steps to reproduce
  1. Request a Review Helper review on a revision. The first review posts its summary and any inline findings.
  2. Upload a new diff that addresses the findings.
  3. Request another Review Helper review.
  4. If the re-review generates no findings, inspect the revision timeline and try requesting another review for the same diff.

D325624 demonstrates this with Diff 1374611. Review Helper reports:

Review Helper already posted its review for Diff 1374611.

However, the revision timeline contains Review Helper output only for the previous Diff 1374609. There is no visible transaction for Diff 1374611.

Actual behavior

Subsequent reviews intentionally omit the patch summary, following https://github.com/mozilla/bugbug/issues/5869. If the review also has no inline findings, differential.createcomment receives no message and no inline comments. Phabricator accepts the no-effect transaction, and Review Helper records the request as published, but nothing appears in the revision timeline.

From the revision alone, reviewers cannot distinguish a successful review with no findings from a request that was never made, is still processing, or failed silently. The only confirmation is attempting another request and receiving the “already posted” dialog.

Expected behavior

Post a lightweight completion transaction for a subsequent review with no findings, without repeating the patch summary. For example:

Review Helper completed its review of Diff 1374611 with no new comments.

This would preserve the reduced-noise behavior from https://github.com/mozilla/bugbug/issues/5869 while providing an auditable completion signal.

Relevant implementation

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in services/reviewhelper-api/app/review_processor.py at the subsequent-review message handling and compare it with the first-review summary path. Then inspect services/reviewhelper-api/app/routers/internal.py to understand when publication is marked complete. Done means a no-finding subsequent review leaves a visible completion transaction without repeating the patch summary.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
api, backend
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
78/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.