Last modified: 2012-03-11 00:48:50 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 T14129, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 12129 - Log events occasionally not logged
Log events occasionally not logged
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
1.12.x
All All
: Low major with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/wiki/File:68p...
: testme
: 14826 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-27 05:42 UTC by Daniel Cannon (AmiDaniel)
Modified: 2012-03-11 00:48 UTC (History)
9 users (show)

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


Attachments
Some relevant queries on the toolserver. (24.02 KB, text/plain)
2007-11-27 05:42 UTC, Daniel Cannon (AmiDaniel)
Details

Description Daniel Cannon (AmiDaniel) 2007-11-27 05:42:33 UTC
Created attachment 4385 [details]
Some relevant queries on the toolserver.

I have been unable to replicate this issue on a local wiki; however, it appears that occasionally edits can be patrolled without the patrolling being logged. A quick query revealed 154 edits on enwikibooks and 2589 edits on dewiki that are marked as patrolled but for which no entry exists in the patrol log (see attached query for enwikibooks). 

A quick glance at the time of the edits (in this case all page creations) suggests that these unlogged patrolled edits all occurred at similar times and that, for instance, between 18 and 19 o'clock (UTC) on Nov. 16 all new page creations that were autopatrolled (by sysops) were not logged. My hypothesis would be that this may be due to database replication lag--that is, the page is newly created and automatically marked as patrolled (or someone marks it as patrolled immediately after the page is created); when generating the log, it checks for existence of the page, fails to find it, and aborts adding the log entry. Is it possible that something is working off the slave db that should be working off the master?

I've also come across a few cases where page creations by sysops (that should be autopatrolled) have an entry in the patrol log that indicates the page was manually patrolled. This is likely related to the above problem. I've attached a query illustrating this too.
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-11-28 01:47:30 UTC
(In reply to comment #0)
> My hypothesis
> would be that this may be due to database replication lag--that is, the page is
> newly created and automatically marked as patrolled (or someone marks it as
> patrolled immediately after the page is created); when generating the log, it
> checks for existence of the page, fails to find it, and aborts adding the log
> entry. Is it possible that something is working off the slave db that should be
> working off the master?

A cursory look at instances of wfGetDB() when saving a new page with Wikimedia-ish new pages configuration suggests no (no patrol-related function appears to call a slave in that case, which is correct), but that's not definitive.
Comment 2 Aaron Schulz 2008-04-27 23:31:18 UTC
*** Bug 13863 has been marked as a duplicate of this bug. ***
Comment 3 Aaron Schulz 2008-04-27 23:39:33 UTC
Should be fixed in r33951.
Comment 4 Aaron Schulz 2008-04-28 01:01:50 UTC
Re-open per comment by Tim. This is still up in the air.
Comment 5 Aaron Schulz 2008-05-01 22:30:52 UTC
Does anyone actually get database error messages when this happens?
Comment 6 Aaron Schulz 2008-07-19 05:59:34 UTC
*** Bug 14826 has been marked as a duplicate of this bug. ***
Comment 7 Mike.lifeguard 2008-08-08 17:22:31 UTC
(In reply to comment #5)
> Does anyone actually get database error messages when this happens?
> 

In the original case regarding the patrol log at en.wikibooks, there was no error message of any kind. Things seemed to work normally - only when you check the log was there any indication of a problem.
Comment 8 Mike.lifeguard 2008-11-25 04:19:34 UTC
Any progress on figuring this out? Do we know whether similar errors happen for other log types? For example in bug 13863 there are deletions which are not being logged properly.
Comment 9 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-11-25 14:24:11 UTC
As with most things that aren't reproducible, it's hard to be sure if this is fixed.  There were some commits a couple of months ago that tried to fix it.  If it's still occurring (is it?), then evidently there hasn't been progress, or at least it hasn't been perfect.
Comment 10 Mike.lifeguard 2009-07-19 19:10:09 UTC
(In reply to comment #9)
> If it's still occurring (is it?), then evidently there hasn't been progress, or
> at least it hasn't been perfect.
> 

It is. In particular, Commons users notice unlogged (and sometimes incomplete) deletions like http://commons.wikimedia.org/wiki/File:Dan_Brown.jpg

Would listing cases here help figure out what's going on?
Comment 11 MBisanz 2009-07-20 00:13:12 UTC
I run into this on a daily basis, sometimes dozens of time, when deleting images on enwiki with Twinkle through the API.  http://en.wikipedia.org/wiki/File:68px-Picture_10.png is an example of a file that was deleted, but not logged and the file description page was left intact.  This is a rather major problem in tracking deletions for us.
Comment 12 Max Semenik 2012-03-08 19:51:33 UTC
Is this bug still being observed?
Comment 13 MBisanz 2012-03-08 21:13:05 UTC
It's happened a couple of times recently on Commons with script-based image deletions. I can't think of any specific examples though.
Comment 14 MZMcBride 2012-03-09 02:49:08 UTC
I checked the logged uploads on Commons from 2012. For every non-existent file, there was a deletion or move log entry. There have been about 480,000 uploads to Commons so far this year. The only anomaly was <https://commons.wikimedia.org/wiki/File:Amalie_Bensinger,_Portrait_einer_Italienerin.jpg>, which is a file with an upload log entry, but the file description page does not exist. However, this anomaly is the subject of other bugs. I think _this_ bug can probably safely be closed unless there's evidence of further issues.

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


Navigation
Links