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.
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
[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 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.
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.
@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.