review stats do not update on moderation or removal of reviews

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)
}}}

Thanks Michael for your reply. The problem that this bug describes is that even after the cache expired the data is still wrong (or appears to be wrong). It looks like a review in moderation is not affecting the stats. I did a moderation request on the reviews for 2vcard yesterday (~24h ago) and all of them are in the moderation queue currently. But the stats still count them today:
$ w3m -dump https://reviews.staging.ubuntu.com/reviews/api/1.0/review-stats/|grep -B4 -A1 2vcard
    {
        "ratings_total": 8,
        "ratings_average": "3.75",
        "app_name": "",
        "package_name": "2vcard"
    },

I agree that we need to provide the caching and that the client will have to do tricks in order ot update its data (its doing that to some extend already).

@noodles, as mvo points out, what we should ensure is that eventually (after some caching period) the results should be consistent again. In other words, our database should be kept consistent, even though caching may produce (temporarily) inconsistent data. At the moment our data loses consistency when a review is flagged or deleted.

Ah right - thanks guys. achuni did mention that in the irc conv., but I missed that on the bug.

Passes on production.