review stats do not update on moderation or removal of reviews
Bug #708841 reported by
Michael Vogt
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ratings and Reviews server |
Fix Released
|
High
|
Michael Nelson |
Bug Description
When a review is flagged for moderation or removed permanently the review stats are not updated.
E.g.
$ w3m -dump https:/
{
"app_name": "7zip",
},
But all of those are in moderation (they are test review entries and removed).
Notes:
The stats should be updated whenever a review is hidden or un-hidden. When a review is initially flagged, it will be hidden. But if it is flagged again after already having been approved via moderation, it will not be hidden.
Related branches
lp:~michael.nelson/rnr-server/708841-caching-issue
- Danny Tamez (community): Approve
-
Diff: 155 lines (+58/-3)2 files modifiedsrc/reviewsapp/models/reviews.py (+11/-3)
src/reviewsapp/tests/test_models.py (+47/-0)
summary: |
- review stats do update on moderation or removal of reviews + review stats do not update on moderation or removal of reviews |
Changed in rnr-server: | |
assignee: | nobody → Michael Nelson (michael.nelson) |
importance: | Undecided → High |
status: | New → In Progress |
tags: | added: kb-task |
Changed in rnr-server: | |
status: | In Progress → Fix Committed |
description: | updated |
description: | updated |
Changed in rnr-server: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
Just noting that I'm not sure whether we're talking about a feature or a bug here. That is, we wanted to ensure that the views behind the stats URLs would only ever be hit when their cache timed out (very heavily cached).
It obviously looks wrong when the example stats only contain one package, but when it contains 10k we can't be clearing the cache for this url each time a review is flagged.
It was because this request will potentially be so heavy on the server that we enabled tho /review- stats/last- [1,3,7] -days/ urls, on the assumption that clients would be requesting updated stats at *most* once-per-day.
From memory, we had a conversation along the lines of the USC client updating its local copy for individual packages when the user adds a review, or flags a review etc. (so at least their own modifications look consistent).
{{{
12:16 * noodles is confused about the stats bug - I thought the whole point was that url should be very heavily cached?
12:17 < noodles> (ie. the cache for the stats should not be cleared every time a moderation is flagged etc.)
12:25 < achuni> noodles: right, but even after cache has expired, stats never go away
12:26 * achuni checks the stats bug
12:27 < achuni> yup
12:27 < noodles> Oh? OK.
12:28 < achuni> noodles: ie, flagging a stat should decrease the stats for the software item (or moderating the flag, at the latest)
12:29 < noodles> achuni: flagging a review? I don't see how that's possible while heavily caching that url (as the client downloads *complete* stats)
12:29 < noodles> (ie. we wanted to be able to write the file out regularly and just server the static file, from memory)
}}}