Page MenuHomePhabricator

When owner of Owners package is a project, audit triggers even when member of project signs off
Closed, ResolvedPublic

Description

repro:

  1. project: ops
  2. owners package: ansible, path: src/ansible, owner: ops, auto review: review blocking, auditing: enabled
  3. submit review touching code in src/ansible
  4. ops gets added as reviewer, all members of ops get notified
  5. a member of ops accepts the review, review is marked as having been accepted from ops
  6. author commits

expect: review was accepted by member of owning project, commit should not be flagged for audit

actual: commit flagged as needing audit, "Group Auditors: O1: ansible Owners Not Involved"

another scenario that erroneously triggers this behavior: member of ops submits review, accepted by different member of ops, commit flagged for audit with "Owners Not Involved"

Event Timeline

Before I dig into this, is there any possibility this was a daemon running old code? I don't remember if I tested this explicitly and it could quite reasonably be an upstream bug, but the code at least attempts to check for this, and D15939 theoretically fixed issues with this.

I will manually restart everything and reproduce again

confirmed.

  1. manually restarted php5-fpm and phd services
  2. colleague, member of ops submitted review touching src/ansible
  3. that review doesn't explicitly list "ops" as blocking reviewers because he's also an owner of ansible, but it does highlight my review in yellow
  4. he lands it after I accept it
  5. his commit is flagged for review despite both of us being members of ops

the exact same behavior is if someone outside of ops authors the review and commit, except then the review has an explicit "Group Auditors" section.

chad renamed this task from when owner of Owners package is a project, audit triggers even when member of project signs off to When owner of Owners package is a project, audit triggers even when member of project signs off.May 23 2016, 10:43 PM
chad added a project: Owners.

This was a legitimate upstream bug and I was able to reproduce it by following your steps, thanks for the report. D15971 should resolve it.

epriestley triaged this task as Normal priority.