Last modified: 2013-04-25 12:38:48 UTC
After running a maintenance script (multiple times - had error for dewiki first time) to merge legacy AFTv5 entries to the new db cluster, incorrect filter totals are being displayed. This appears to be caused by having visited an article feedback page during when the maintenance script was running and/or had completed with incorrect data. From the moment the data has been fetched once, it remains in cache forever (the query alternative is expensive) and upon adding/deleting/updating new entries, the cached totals are updated. Unfortunately, when moderating AFTv5 entries now, the totals that are being updated are incorrect to start from. A maintenance script to purge caches exists: extensions/ArticleFeedbackv5/maintenance/purgeCache.php. It can not be used though, since mwscript runs against pmtpa memcached servers & web requests eqiad.
If no solution to be able to manipulate (in this case: purge) eqiad MC caches from fenari, I could change all cache keys to use a different prefix. This would result in new caches to be used and populated. I'd rather not do this though, since the left-over, unused keys are all permanent (do not expire)
[Making bug summary more specific, to differentiate from bug 46423]
(In reply to comment #0) > A maintenance script to purge caches exists: > extensions/ArticleFeedbackv5/maintenance/purgeCache.php. It can not be used > though, since mwscript runs against pmtpa memcached servers & web requests > eqiad. Note: Aaron stated in https://bugzilla.wikimedia.org/show_bug.cgi?id=46428#c16 that "MWScript.php and mwscript are working now after some permission fixes by Peter and after https://gerrit.wikimedia.org/r/#/c/58124/, so I think terbium starting to get usable. I'll probably start running some scripts on it today myself." If there is something else blocking progress here, could somebody please elaborate what's needed?
That blocker should indeed be resolved & I'll start purging the caches during the deployment window later today. If all goes well, that should fix it.
(In reply to comment #4 by Matthias Mullie) > That blocker should indeed be resolved & I'll start purging the caches during > the deployment window later today. > If all goes well, that should fix it. Matthias: Did it? If not, any timeframe?
It did fix it!
