Last modified: 2013-07-25 07:07:43 UTC
Created attachment 12020 [details] Async I'm not yet entirely sure what's causing the issue. I've just looked at the examples (see screenshot) and they are correct now. It appears that all the data in the end is correct - luckily. I believe this is caused because for the list-views, I can't update in cache right away. Instead, I purge the list-views, and wait until someone requests it, at which point what is fetched from the database is saved in cache again. The problem here would be that (especially for the central feedback page) data is requested again really fast, and from a slave that has not caught up. And from that point is saved in cache for an hour in an incorrect state. That's what I think is the problem. I've got an idea to make it possible to update the caches immediately (and circumvent having to rebuild the data from the database on a follow-up request), but I'll have to investigate it some more.
Related URL: https://gerrit.wikimedia.org/r/58706 (Gerrit Change I5653fa1bbdbec474ae91e281fdf4381f00db3975)
https://gerrit.wikimedia.org/r/#/c/58691/ & https://gerrit.wikimedia.org/r/#/c/58706/ should help alleviate this problem.
https://gerrit.wikimedia.org/r/58706 (Gerrit Change I5653fa1bbdbec474ae91e281fdf4381f00db3975) | change APPROVED and MERGED [by jenkins-bot]
To let you know, I still can reproduce this today (2013-04-18). It's very easy to reproduce. It happens every time. 1. Go to the central feedback page. 2. Click the "unreviewed" filter. 3. Moderate one of the posts. 4. Click "unreviewed" again. Obviously the list reloads from a client side cache. It reloads very fast (no server request is done). It shows the list from step 2. The moderation is gone. When I try to moderate the same post again I get the new error message about being out of sync. This message helps a lot to understand whats going on but does not solve the problem. I'm doing this tests in the German Wikipedia with Internet Explorer 9 on purpose.
Related URL: https://gerrit.wikimedia.org/r/59816 (Gerrit Change I0bffc61e6203c91682d70e5c1dae5134af044ca5)
Now that's some awesome feedback. I've been able to reproduce the issue on IE9 (Firefox, Safari and even cache meister Chrome seem to do just fine) It looks like indeed IE9 just servers client-side cached requests again. A refresh will "fix" it, so it's not really an issue of faulty data. I've just pushed a patch that will make sure IE9 also busts any client-side caches (by letting the ajax-call add a timestamped parameter)
Did you found a good solution? When will it be deployed to the Wikipedia projects? Currently I still have the bug in both English and German Wikipedia projects.
Yes, the patch is in Gerrit already (https://gerrit.wikimedia.org/r/#/c/59816/) and I hope we'll get it merged and deployed next week.
*** Bug 46796 has been marked as a duplicate of this bug. ***
Gerrit patch in comment 9 got merged, can this bug report get closed as RESOLVED FIXED or is there anything else to do?
Still the same issue in Internet Explorer 9 in both English and German Wikipedia.
Patch got merged on May 06th, and assuming that AFTv5 follows the standard deployment schedule at https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap , en.wp will receive the fix on Monday 20th and de.wp on Wednesday 22nd.
So it is not fixed and you have no prove it will be fixed on May 20th or 22nd. Please leave such reports open till they are actually fixed. Else people will think this is a regression.
VERIFIED (a merged patch has been proven to work) is a different step (and Bugzilla status) from RESOLVED FIXED (a patch to fix has been merged into the codebase). Verification is highly welcome once a patch has been deployed, but optional. I agree that "fixed" vs "deployed" is currently confusing in Bugzilla (and not clear at all to anybody who does not know the deployment schedule, which probably means 98% of Bugzilla users), so I'm considering introducing a status "RELEASED" to be set after deployment or something similar.
(In reply to comment #14) > Please leave such reports open till they are actually fixed. Else people will > think this is a regression. This is fixed, the patch is merged. RESOLVED FIXED indicates that the software is fixed, not that <insert name of your favourite wiki here> is updated to use the latest software, and will never mean that - otherwise one hugely out of date setup anywhere could mean all bugs would have to stay open.
(In reply to comment #16) > not that <insert name of your favourite wiki here> is updated Obviously you don't know much about the Article Feedback extension and how it is developed and tested. So please don't tell me how you think this works.
(In reply to comment #17) > (In reply to comment #16) > > not that <insert name of your favourite wiki here> is updated > > Obviously you don't know much about the Article Feedback extension and how it > is developed and tested. So please don't tell me how you think this works. Alex' comment refered was generally refering to Bugzilla status, not to <name of your extension> specifically, and Alex is right in describing "how it works". TMg: No reason to be passive aggressive.
TMg - just want to confirm (now that the fix should've been deployed on dewiki already): did this accurately fix the problem for you?
I can't reproduce this any more with Internet Explorer 9. Thanks for asking. This crazy bug was really annoying and I'm a bit sad it took sooo long to get it fixed in the Wikipedia projects. That time the tool was almost completely useless for some users. :-(
