Last modified: 2012-06-15 13:25:43 UTC
The RSS feeds for non-existant pages are getting spurious updates about other, unrelated pages, being renamed. Examples: * http://en.wikipedia.org/w/index.php?title=Image:Madison_Wisconsin_Flag.svg&feed=rss&action=history - Page used to exist; was moved to Mediawiki. * http://en.wikipedia.org/w/index.php?title=Image_talk:Varicella_computer_game_screenshot.png&feed=atom&action=history - Page never existed, but matching article does. * http://en.wikipedia.org/w/index.php?title=Olitext&feed=atom&action=history - Deleted article The feed contains reported updates and links that to the matching article's history. Since the article doesn't exist, obviously the links don't work. Expected behavior: No updates. Perhaps an empty feed, or a feed with a single static entry (with a non-changing GUID and date!) saying that no such article exists. Now it may seem silly to follow feeds for non-existant pages, but it an be useful if you want to know if a page is later created. This is especially likely if you are following an article that does exist, but no matching talk page yet exists.
Created attachment 6266 [details] Detect requests for a history feed of a non-existant article If the article does not exist, the fetchRevisions() function blindly passes the $this->mTitle->getArticleID() (which is zero), to the query, returning all revisions with rev_page=0. I guess there should be none, anyway, but 1. there is no point in doing that, 2. it seems that on Wikimedia servers, there are some (see the abovementioned URL). Either way, there is some code already that copes with an empty feed, so just be checking for a nonexisting page, we begin using that. The resulting feed is not perfect, though.
Fixed in r59730.
Reverted myself in r59737.
Alan, is this problem still happening? Can you still reproduce it? Mormegil, as you can see in the comments for https://www.mediawiki.org/wiki/Special:Code/MediaWiki/59730 and https://www.mediawiki.org/wiki/Special:Code/MediaWiki/59737 , Chad originally committed your patch, but had to revert it because it caused some warnings, as well as a possible regression. Now, the codebase has changed enough that your patch doesn't apply cleanly to trunk anymore. I'm sorry. If you have the time and the interest to update and revise your patch, please do! Thanks for the contribution.
Comment on attachment 6266 [details] Detect requests for a history feed of a non-existant article Patch is obsolete and no longer applies cleanly against trunk, per http://lists.wikimedia.org/pipermail/wikitech-l/2011-November/056340.html automated testing.
Sumana, yes, I'm still seeing it. I've seen spurious updates go by as recently as November 11th, 2011. Two of the original examples I gave still have spurious updates (the last has since become a "real" page): * http://en.wikipedia.org/w/index.php?title=Image:Madison_Wisconsin_Flag.svg&feed=rss&action=history * http://en.wikipedia.org/w/index.php?title=Olitext&feed=atom&action=history A few other pages that I saw go by in my RSS aggregator recently: * http://en.wikipedia.org/w/index.php?title=User:Alan_De_Smet%2FGoOFF&feed=atom&action=history * http://en.wikipedia.org/w/index.php?title=Xlear_Nasal_Wash&feed=atom&action=history * http://en.wikipedia.org/w/index.php?title=Image_talk:Aaron_Williams_of_Nodwick_at_Gen_Con.jpg&feed=atom&action=history
Created attachment 9598 [details] Updated patch (In reply to comment #4) > If you have the time and the interest to update and revise your patch, please > do! The reasoning behind is bascially still the same – the only thing that changed is that fetchRevisions() now returns a ResultWrapper instead of a simple array (and performs “->numRows()” on it), so we need to return that. (There were more possible solutions here, I chose the simplest one.)
Mormegil, thanks for the update. I suggest you submit it directly into Git, our source control system. You can do that with developer access: https://www.mediawiki.org/wiki/Developer_access That way it'll get reviewed faster. Thanks!
Patch committed with Gerrit change #10752 and successfully merged.
