Last modified: 2009-01-10 13:21:46 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T17659, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 15659 - cache problem: old revisions are shown
cache problem: old revisions are shown
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
FlaggedRevs (Other open bugs)
unspecified
All All
: Normal normal with 1 vote (vote)
: ---
Assigned To: Aaron Schulz
http://ru.wikipedia.org/wiki/МКБ-10:_...
:
: 15727 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-20 13:57 UTC by Ilya Schurov
Modified: 2009-01-10 13:21 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Screenshot of bug (33.57 KB, image/gif)
2008-09-21 14:49 UTC, Kolbenfresser
Details
Screenshot of same article while logged out (39.88 KB, image/gif)
2008-09-21 14:49 UTC, Kolbenfresser
Details

Description Ilya Schurov 2008-09-20 13:57:41 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).
Comment 1 Aaron Schulz 2008-09-20 14:22:36 UTC
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.
Comment 2 Ilya Schurov 2008-09-20 14:28:07 UTC
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).
Comment 3 Aaron Schulz 2008-09-20 14:45:02 UTC
OK, didn't noticed the CSS or JS color hiding.
Comment 4 Aaron Schulz 2008-09-20 14:47:07 UTC
Does it happen on edit or on review?
Comment 5 Ilya Schurov 2008-09-20 15:23:49 UTC
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.
Comment 6 Aaron Schulz 2008-09-20 15:25:33 UTC
Are they for auto-sighted edits?
Comment 7 Ilya Schurov 2008-09-20 15:27:38 UTC
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.
Comment 8 Ilya Schurov 2008-09-20 15:28:44 UTC
(In reply to comment #6)
> Are they for auto-sighted edits?
> 

No, the article under consideration wasn't auto-sighted.
Comment 9 Aaron Schulz 2008-09-20 15:38:35 UTC
(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.
Comment 10 Ilya Schurov 2008-09-20 15:49:00 UTC
Hm. OK. So the question is: why it wasn't updated properly by edits after initial sighting?..
Comment 11 Aaron Schulz 2008-09-20 15:57:03 UTC
Possibly fixed in r41072. Transactions splitting of the review and link tracking was removed there, so they all either fail or succeed.
Comment 12 Kolbenfresser 2008-09-21 14:49:06 UTC
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).
Comment 13 Kolbenfresser 2008-09-21 14:49:37 UTC
Created attachment 5354 [details]
Screenshot of same article while logged out
Comment 14 Kolbenfresser 2008-09-21 15:25:07 UTC
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.
Comment 15 Ilya Schurov 2008-09-22 21:41:13 UTC
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).
Comment 16 Ilya Schurov 2008-09-23 10:45:38 UTC
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. 
Comment 17 Aaron Schulz 2008-09-23 10:51:19 UTC
A null edit on the proper page fixed it
Comment 18 Ilya Schurov 2008-09-23 10:58:24 UTC
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.
Comment 19 Aaron Schulz 2008-09-26 16:45:48 UTC
*** Bug 15727 has been marked as a duplicate of this bug. ***
Comment 20 Aaron Schulz 2008-09-27 22:54:03 UTC

*** This bug has been marked as a duplicate of bug 8748 ***
Comment 21 René Kijewski 2008-09-29 02:08:59 UTC
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.
Comment 22 Aaron Schulz 2008-09-29 02:41:04 UTC
(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.
Comment 23 René Kijewski 2008-09-30 04:32:48 UTC
(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 ;-) ).
Comment 24 Ilya Schurov 2008-09-30 07:54:59 UTC
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)?
Comment 25 René Kijewski 2008-09-30 14:50:01 UTC
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 :-)
Comment 26 Ilya Schurov 2008-09-30 14:56:57 UTC
I belive the real thing you need is not a timestamp of oldid, but timestamp of actual sighting moment.
Comment 27 René Kijewski 2008-10-03 01:46:40 UTC
(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.
Comment 28 P.Copp 2009-01-10 04:53:18 UTC
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
Comment 29 Melancholie 2009-01-10 05:06:50 UTC
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?
Comment 30 P.Copp 2009-01-10 05:14:36 UTC
Have you tried to reproduce this bug like I described above, on one wiki with FlaggedRevs and one without? 
Comment 31 Melancholie 2009-01-10 05:37:53 UTC
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.
Comment 32 P.Copp 2009-01-10 05:52:05 UTC
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.
Comment 33 Melancholie 2009-01-10 06:02:04 UTC
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).
Comment 34 Aaron Schulz 2009-01-10 13:21:46 UTC
Fixed in r45633. Was indeed due to unexpected behavior of getContent().

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links