Fix counters when changing ownership with new LocalSiteProfiles.
Review Request #1761 — Created Oct. 16, 2019 and submitted
Information | |
---|---|
guest3621 | |
Review Board | |
c08aa74... | |
Reviewers | |
demo | |
The introduction of review request ownership changes made counters a bit more complex, and for a time broke our outgoing counters. This was largely addressed in commit abc032d20f3b286fb193df4a60340cf6dba8daa6, but there was an edge case being hit by some users. If a new owner's `LocalSiteProfile` didn't yet exist at the time they were made the owner (such as if they had just been added to a `LocalSite` but hadn't logged in yet, or were added by way of an auth backend), then the initial values for their new profile's counters would already be computed when fetched in `_update_counts()`, based on the newly-published draft changes (which would include the ownership change, and possibly reviewer changes). The outgoing counters would be worked around from the previous fix, but incoming counters could be broken. The same problems can also occur even without ownership changes, if the user had created a review request and published via the API or some other form of automation but hadn't yet logged in or triggered a code path creating an initial profile. This is hard to work around if the profile is being created in `_update_counts()`, but the solution is pretty easy. We now ensure we've fetched/created a profile before any part of the draft gets published, giving us stable counters to work with as part of the publish and update steps. This fix lets us remove a bunch of special-cased updates in the previous fix, and will take care of the various edge cases all at once. Unit tests and docs have been enhanced to help us better reason about these counters in the future. Testing Done: Unit tests pass. Reviewed at https://reviews.reviewboard.org/r/10721/