Last modified: 2012-03-11 00:48:50 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.
(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.
*** Bug 13863 has been marked as a duplicate of this bug. ***
Should be fixed in r33951.
Re-open per comment by Tim. This is still up in the air.
Does anyone actually get database error messages when this happens?
*** Bug 14826 has been marked as a duplicate of this bug. ***
(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.
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.
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.
(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?
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.
Is this bug still being observed?
It's happened a couple of times recently on Commons with script-based image deletions. I can't think of any specific examples though.
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.
