Last modified: 2014-02-25 23:51:20 UTC
Created attachment 10161 [details] screenshot There's a string of giberish numbers appearing in place of x.y for the Article Feedback Tool, version 4
Yes, I'm seeing this in lots of articles. It's giving ratings that are in the millions instead of between 1 and 5.
I can not reproduce this locally and - at first glance - find no mistakes in code. However, when visiting http://en.wikipedia.org/wiki/Cancer_pain (the one from the screenshot) - the bug no longer seems to occur. Investigating the ajax-call to get the totals, I only find 1 vote, with all fives. Based here-on, I'm assuming *someone* stumbled upon corrupted database data and cleared it. Please let me know if you run into another page displaying incorrect totals.
This bug is something of a moving target. Try taking a look at Anne Dallas Dudley on en.wiki.
I also can't reproduce locally, but the code that generated the averages was obnoxious, so I replaced with something sensible it in https://gerrit.wikimedia.org/r/#/c/14148/. Maybe this will fix it.
Doesn't seem to have fixed the problem :(
It looks like the problem is caused by entries in the article_feedback_revisions table where the afr_count is 0 and the afr_total is something like 4294967295. If the afr_count is 0, I imagine the afr_total should also be 0. Indeed, I'm not even sure what the point of these 0 entries are and it looks like most articles don't have them.
Looks like the zero entries are from when someone rates one criteria, but not the others. According to the database, there are currently 2891 entries in the article_feedback_revisions table with bogus afr_total values. Only about half of them also have afr_count values of 0.
A good start on cleaning the bad data would be running something like: UPDATE article_feedback_revisions SET afr_total = 0 WHERE afr_count = 0 AND afr_total > 1000000000; That table is huge though, so we might want to use a maintenance script that first pulls the effected page IDs from a slave DB, and then target those page IDs specifically in the master table. Like I said though, this would only fix about half of them.
