Last modified: 2009-01-10 13:21:46 UTC
The following problem occurs rather often on ruwiki: we have pages that are shown in non-latest revision, but in some previous. It seems to be cache problem: &action=purge solve this. Different revision can be shown for different users (e.g. it depends on whether the user logged in or works anonymously, sometime different revisions of the same page can be shown to two logged in users). Job queue doesn't looks too long (e.g. 127). The problem can be connected with FlaggedRevs extension (sometimes it's the last sighted revision which is shown to users, but re-sighting last revision doesn't help sometimes).
The page in the url has no reviewed revisions. It's not likely it is flaggedrevs. Also, .de doesn't appear to have this issue.
Aaron, it do have reviewed (sighted) revisions (the marks are hidden for anons and users without "editor" flag, you may be needed to turn off Javascript to see them). However, I do not have strong evidence it's FlaggedRevs issue now. But it first occur when we began massive sighting of old articles using bots. It can be coincidence thought and some people said "we see last sighted revision, just like the page is stabilized" -- that's not the case in URL (because here we have the last revision sighted).
OK, didn't noticed the CSS or JS color hiding.
Does it happen on edit or on review?
I'm not sure. We have only reports like "oh, I don't see nl-interwiki on that page, but it should be there, because it was added in this revision". So it seems nobody say "I added this interwiki, but can't see it in new version". But I'm not sure, because it's not easy to reproduce the problem.
Are they for auto-sighted edits?
We have another one problem. I believe it is related to this bug, but not sure (maybe I should post another bug instead). We have articles which are included in some category. When I open the article, I see it belongs to the category. But when I open category, I don't see the article there. When the article was sighted, it did not belong to the category. But when I sight some revision (not the last, and not even that revision in which the article belongs to the category), it appears in the category. Note that &purge=1 on article and category does not help. Only sighting.
(In reply to comment #6) > Are they for auto-sighted edits? > No, the article under consideration wasn't auto-sighted.
(In reply to comment #7) > We have another one problem. I believe it is related to this bug, but not sure > (maybe I should post another bug instead). We have articles which are included > in some category. When I open the article, I see it belongs to the category. > But when I open category, I don't see the article there. When the article was > sighted, it did not belong to the category. But when I sight some revision (not > the last, and not even that revision in which the article belongs to the > category), it appears in the category. > > Note that &purge=1 on article and category does not help. Only sighting. > This is because sighting triggers LinksUpdate, which null edits also do. This corrects links tracking and such.
Hm. OK. So the question is: why it wasn't updated properly by edits after initial sighting?..
Possibly fixed in r41072. Transactions splitting of the review and link tracking was removed there, so they all either fail or succeed.
Created attachment 5353 [details] Screenshot of bug Same on dewiki. Example reported a few minutes ago: [[de:Funk (Musik)]], shows a very old revision when viewing while logged in. Anons seem to get the current revision (which is sighted).
Created attachment 5354 [details] Screenshot of same article while logged out
Note: The page was purged after the report, which fixed the issue, so you can't see it there anymore. The shown revision was http://de.wikipedia.org/w/index.php?oldid=122540 from May 2003, though not the first revision of that page.
We have reports that the cache problem mentioned in the initial description of this bug occurs in the "Wikipedia:" namespace (on page http://ru.wikipedia.org/wiki/Википедия:Кандидаты_в_хорошие_статьи/Журнал_избраний). This namespace is not reviewable in ruwiki. So it seems that it's not FlaggedRevs problem (at least, not ''only'' FlaggedRevs problem). So I believe the bug should be assigned to wikibugs-l again (at least, we should have wikibugs-l in CC).
We have another problem with WhatLinksHere feature, which may be related to Category problem described in comment #7. http://ru.wikipedia.org/wiki/Служебная:WhatLinksHere/Спрыгин,_Иван_Иванович does not list the article http://ru.wikipedia.org/wiki/Жигулёвский_заповедник which links to [[ru:Спрыгин, Иван Иванович]]. Note that the latter article was bot-sighted as some other articles where the problem occur. However, now it was re-sighted in latest revision, and it doesn't help in updating WhatLinksHere. Neither dummy edit of this article help, which is a bit strange for me.
A null edit on the proper page fixed it
OK, thanks. I'm not very familar with internal MediaWiki structure yet :) However, I should note that [[ru:Жигулевский заповедник]] was also bot-sighted in the revision which did not link to [[ru:Спрыгин, Иван Иванович]]. Unfortunately, it was before r41072 deployed, so we still don't know if it's fixed now.
*** Bug 15727 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 8748 ***
Why is it a duplicate of bug 8748? The there mentioned bug seems to only happened once, and might be a client (or provider) side caching problem. (Five version or one day old...) The bug described here only happens to logged in users and reviewed articles.
(In reply to comment #21) > The bug described here only happens to logged in users and reviewed articles. > The bug report doesn't say that.
(In reply to comment #22) > (In reply to comment #21) > > The bug report doesn't say that. > I thought I read so. It doesn't happen on unreviews articles. It's kinda disgusting, when one is tracking the recent changes, and has to purge the cache (with normally no purge button at all). First you only overview the diff, but often it is needed to view the whole page, and then it seems the edit never happed. I still don't think this bug is a duplicate. It should be assigned to the flagging extension and be re-opened (but you are the developer ;-) ).
I can say that this bug can be definitely triggered by FlaggedRevs, but it's not only FlaggedRevs as it's noted in comment #15 (occurs in non-reviewable namespace as well). So I believe it can be possible dupe of bug 8748. René Kijewski, do you see this cache problems occurs with reviewed pages, which were reviewed last time *after* r41072 is deployed (that is approx. September 21)?
I can't tell, I just had it this morning and wrote this comment afterwards. I will pay attention to the timestamp of the oldid next time, I promise :-)
I belive the real thing you need is not a timestamp of oldid, but timestamp of actual sighting moment.
(In reply to comment #26) > I belive the real thing you need is not a timestamp of oldid, but timestamp of > actual sighting moment. > You are right. The problem does not occure for version flagged after (at least) 1st october.
Reopening, as this still occurs on dewiki every couple of days[1]. The pattern is always the same: current revision is sighted, anons see the current revision, but logged-in users see a very old revision from parser cache. After purging the page, the problem disappears. I finally managed to reproduce this on my local install. Try the following steps: * Login as an editor * Pick a random article in mainspace and sight the current revision * Select a diff between an old (unsighted) revision and the current one * add '&diffonly=1&action=purge' to the url Now when you ylick on the tab to view the article normally, you should notice, that the old revision is shown (assuming that parser cache is enabled). I'm not totally certain, what the cause for this is, but my guess would be FlaggedRevs::stableVersionIsSynced(), line 512: Seems like Article::getContent pulls the oldid parameter from the request object, so what is saved in the parser cache afterwards will be the parsed old revision, not the current one under certain circumstances. [1] http://de.wikipedia.org/w/index.php?title=Wikipedia:Fragen_zur_Wikipedia&oldid=55139574#Explorer-Brian-Kuriosum
Is FlaggedRevs really the correct component for this bug? Such cache bugs occur on *all* Wikimedia wikis (I know for sure), regardless whether FlaggedRevs is installed or not. This cache problem is years old actually, and it most often occurs when our server are struggling (like currently, while much hardware is moved from A to B). Hasn't there been another bug report for "old rev shown", actually?
Have you tried to reproduce this bug like I described above, on one wiki with FlaggedRevs and one without?
I do not know whether your bug report is quite the same as the initial one ;-) But both are cache issues. Just wanted to point out that this may (also) be a core issue, maybe. Maybe it just becomes more apparent in combination with FlaggedRevs, as this is a cache based extension.
Sorry, I just don't get your point. This bug is about a very specific problem with the parser cache handling in FlaggedRevs. It is easily reproducible as I described and can certainly be tracked down with a bit of debugging. If you know of other parser cache related issues in wikis without FlaggedRevs, fine. Feel free to file a bug about it or append to an existing one, but these thing are probably not related at all to this specifig bug.
I do not see that in the initial post. Just wanted to emphasize the considerations of Aaron, see comment #20, sorry (just meant that this might *not just* be a FlaggedRevs issue).
Fixed in r45633. Was indeed due to unexpected behavior of getContent().
