Page MenuHomePhabricator

Some reuploads can't be patrolled
Open, LowPublic

Description

Sometimes reuploads don't trigger a [Mark this file version as patrolled] link on the file description page although they are displayed at Special:NewFiles as unpatrolled.

The link is correctly displayed for this file, but not for this one, even though both are unpatrolled.

Event Timeline

Cenarium created this task.Jan 15 2016, 3:44 PM
Cenarium raised the priority of this task from to Needs Triage.
Cenarium updated the task description. (Show Details)
Cenarium added a subscriber: Cenarium.
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptJan 15 2016, 3:44 PM
Cenarium set Security to None.
Cenarium added a subscriber: matmarex.

I think this might be due to the timestamp between the null revision and RC log entry being slightly different. I had the same issue when testing move patrol for T98617 in https://gerrit.wikimedia.org/r/#/c/251794/. Rearranging MovePage.php so that the recent change is published faster after the null revision fixed it. So we might have to modify LocalFile.php.

matmarex added a comment.EditedJan 20 2016, 4:34 PM

I think this might be due to the timestamp between the null revision and RC log entry being slightly different.

All the timestamps are the same in this case, though.

imageinfo: "2016-01-15T11:31:32Z" https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&prop=imageinfo&format=json&iiprop=timestamp&iilimit=max&titles=File%3APlaylist-theverybestofyannicover.jpg
revisions: "2016-01-15T11:31:32Z" https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&prop=revisions&format=json&rvprop=timestamp&rvlimit=max&titles=File%3APlaylist-theverybestofyannicover.jpg
logevents: "2016-01-15T11:31:32Z" https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&list=logevents&format=json&leprop=type%7Ctimestamp&letitle=File%3APlaylist-theverybestofyannicover.jpg&lelimit=max
recentchanges: "2016-01-15T11:31:32Z" https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&list=recentchanges&format=json&rcnamespace=6&rcuser=CyberFatal01

Although it's true that this could theoretically be an issue, we're relying on the timestamp of image revision and log entry being the same, but not actually making sure it is. I think we can solve this by calling $logEntry->setTimestamp( $this->timestamp ) in LocalFile.php, without any bigger changes. (The timestamp of page revision can also differ, but that shouldn't matter and it's more difficult to fix.) edit: https://gerrit.wikimedia.org/r/266155

Restricted Application added projects: Multimedia, Commons. · View Herald TranscriptJan 20 2016, 4:34 PM
Restricted Application added a subscriber: Steinsplitter. · View Herald Transcript

[18:04] <MatmaRex> Krenair: could you eval.php something for me, on enwiki? echo ObjectCache::getMainWANInstance()->get( wfMemcKey( 'unpatrollable-page', 45686529 ) ); the output is probably '1', or null.
[18:04] <Krenair> MatmaRex: 1

So I think this is a problem with Article::purgePatrolFooterCache() failing to purge. Is this the issue that 0b3e2ff21f133fc24a0b39260217c798abc82a59 fixed? (That change is not deployed yet.)

Restricted Application added a subscriber: Matanya. · View Herald TranscriptJan 20 2016, 5:06 PM

[18:04] <MatmaRex> Krenair: could you eval.php something for me, on enwiki? echo ObjectCache::getMainWANInstance()->get( wfMemcKey( 'unpatrollable-page', 45686529 ) ); the output is probably '1', or null.
[18:04] <Krenair> MatmaRex: 1
So I think this is a problem with Article::purgePatrolFooterCache() failing to purge. Is this the issue that 0b3e2ff21f133fc24a0b39260217c798abc82a59 fixed? (That change is not deployed yet.)

I don't think so, otherwise it would always fail. Also, at the moment, the latest unpatrolled recent move is retrieved, not the latest recent move. So Article::purgePatrolFooterCache() does nothing - which is what I wanted to fix in https://gerrit.wikimedia.org/r/#/c/263907/.

I merged that change now (it's definitely an improvement), but I'm not convinced that it's going to resolve this. The problematic file page here doesn't seem to have been created before the first upload.

Steinsplitter moved this task from Incoming to Uploading on the Commons board.Jan 22 2016, 5:59 PM
matmarex added a comment.EditedJan 22 2016, 5:59 PM

I ran the same SQL queries as Article::showPatrolFooter would do (if the page wasn't cached as 'unpatrollable-page') on stat1003 and it looks like everything is fine and the patrol link should appear. I'm confident this was caused by Article::purgePatrolFooterCache() not purging the cache during the upload, for whatever reason. If not because of the wrong purge method, then just randomly.

Have you ran into any other files with this problem? I haven't seen any other one.

I think we could just manually purge the cache for this page (I can ask some deployer to do it) and call this a random fluke, unless we see it again.

This isn't an isolated instance, it also happened for this file and others.
It would be interesting to see at commons, which also has RC patrol, whether the diff itself can be patrolled, as they couldn't be either in the tests I had done.

Here's an example at Commons. It can't be patrolled from the footer.
But it can be patrolled from the diff, so it's doesn't look like a timestamp issue.

Poyekhali triaged this task as Normal priority.Apr 13 2016, 5:08 AM

@Pokefan95 As you prioritized this task, do you plan to work on this task? If yes, please also claim the task by setting yourself as assignee. You are not a developer, and we have a bugwrangler to manage prioritizing tasks.

MarkTraceur lowered the priority of this task from Normal to Low.Dec 5 2016, 10:01 PM
MarkTraceur moved this task from Untriaged to Triaged on the Multimedia board.