So the timeline is

• Page starts out being protected against autoconfirmed users
• 17:53, 2 March 2016 BKK EY (talk | contribs) moved page Ernst & Young BKK to EY BKK over redirect (siehe BKK PwC, Benutzer:GUMPi und https://de.wikipedia.org/w/index.php?title=BKK_PwC&diff=150899687&oldid=150899142)
• 2016-03-02T18:44:19 MBq (talk | contribs) protected EY BKK [Move=Allow only editors] (expires 2016-04-02T17:44:19) (Edit-War) (hist)
• 2016-03-02T18:44:51 MBq (talk | contribs) moved page EY BKK to Ernst & Young BKK over redirect (lemmaversion vor edit-war)
• 2016-03-02T18:49:24 BKK EY (talk | contribs) moved page Ernst & Young BKK to EY BKK over redirect (BKK PwC)
• 2016-03-02T18:57:13 MBq (talk | contribs) moved page EY BKK to Ernst & Young BKK over redirect (nochmal)

@Anomie, bawolff and I tried to figure out what was going on here, and not seeing anything obvious. Any chance you see what might have gone wrong?

In T128624#2101106, @csteipp wrote:

There's something else odd with dewiki's custom protection level for 'editors', it doesn't show up on the protection form when using an account with Staff rights.

Maybe try asking the stewards (or get @Jalexander to ask the stewards) to give staff the editeditorprotected right at https://meta.wikimedia.org/wiki/Special:GlobalGroupPermissions/staff ?

In T128624#2101130, @csteipp wrote:

@Anomie, bawolff and I tried to figure out what was going on here, and not seeing anything obvious. Any chance you see what might have gone wrong?

When I try to reproduce locally, I see the following sequence of actions get logged:

2016-03-10 11:30:21 queries INFO: my_wiki: INSERT /* MovePage::move Anomie */ IGNORE INTO `page_restrictions` (pr_page,pr_type,pr_level,pr_cascade,pr_user,pr_expiry) SELECT  2585,pr_type,pr_level,pr_cascade,pr_user,pr_expiry FROM `page_restrictions`   WHERE pr_page = '2582'  
2016-03-10 11:30:21 queries INFO: my_wiki: SELECT /* MovePage::move Anomie */  pr_id  FROM `page_restrictions`   WHERE pr_page = '2585' 
[request finishes...]
2016-03-10 11:30:21 runJobs DEBUG: deleteLinks TestT128624 pageId=2584 (id=1864,timestamp=20160310163021) STARTING
2016-03-10 11:30:21 queries INFO: my_wiki: DELETE /* LinksDeletionUpdate::doUpdate 0:0:0:0:0:0:0:1 */ FROM `page_restrictions` WHERE pr_page = '2582'

In other words, what seems to be happening is that a deleteLinks job is being scheduled for the moved-over redirect, but doesn't take effect until long after the page being moved is already in place. And the job is apparently picking up the new page_id from the title instead of the page_id that was actually deleted. I can't say with certainty that this is what happened on dewiki, but it seems very likely.

Chances are the solution would be to have the deleteLinks job insist on using the passed pageId in preference to the page_id of the existing title. @aaron might be able to tell us more, since deferring jobs like this is his thing.

See https://gerrit.wikimedia.org/r/294034

In T128624#2375516, @aaron wrote:

See https://gerrit.wikimedia.org/r/294034

"The page you requested was not found, or you do not have permission to view this page."

@aaron Please never use Gerrit drafts, and especially never use it for security patches. Your commit can be publicly viewed at https://git.wikimedia.org/log/mediawiki%2Fcore.git/refs%2Fchanges%2F34%2F294034%2F1 (https://git.wikimedia.org/commitdiff/mediawiki%2Fcore.git/dfc043b119213d80105c9e19991f0257a0d59a22).

In T128624#2376367, @matmarex wrote:

Your commit can be publicly viewed at https://git.wikimedia.org/log/mediawiki%2Fcore.git/refs%2Fchanges%2F34%2F294034%2F1 (https://git.wikimedia.org/commitdiff/mediawiki%2Fcore.git/dfc043b119213d80105c9e19991f0257a0d59a22).

Code-Review: +1; Should fix the protection issue that this bug is concerned with. Haven't tested.

Other things that are still likely broken, and should probably be fixed with a public followup patch:

• I note we might still lose non-log recentchanges entries that belong to the new page at the title rather than the old, deleted page since it deletes entries by both rc_namespace+rc_title and by rc_cur_id.
• The 'CategoryAfterPageRemoved' hook function (inside the call to WikiPage::updateCategoryCounts()) will effectively be called on the new page at the title rather than the old. WikiPage::updateCategoryCounts() itself should be fine.

In T128624#2376647, @Anomie wrote:

In T128624#2376367, @matmarex wrote:

Your commit can be publicly viewed at https://git.wikimedia.org/log/mediawiki%2Fcore.git/refs%2Fchanges%2F34%2F294034%2F1 (https://git.wikimedia.org/commitdiff/mediawiki%2Fcore.git/dfc043b119213d80105c9e19991f0257a0d59a22).

Code-Review: +1; Should fix the protection issue that this bug is concerned with. Haven't tested.

Other things that are still likely broken, and should probably be fixed with a public followup patch:

• I note we might still lose non-log recentchanges entries that belong to the new page at the title rather than the old, deleted page since it deletes entries by both rc_namespace+rc_title and by rc_cur_id.
• The 'CategoryAfterPageRemoved' hook function (inside the call to WikiPage::updateCategoryCounts()) will effectively be called on the new page at the title rather than the old. WikiPage::updateCategoryCounts() itself should be fine.

@Anomie Will you create separate tickets for those items?

In T128624#2377132, @dpatrick wrote:

In T128624#2376647, @Anomie wrote:

In T128624#2376367, @matmarex wrote:

Your commit can be publicly viewed at https://git.wikimedia.org/log/mediawiki%2Fcore.git/refs%2Fchanges%2F34%2F294034%2F1 (https://git.wikimedia.org/commitdiff/mediawiki%2Fcore.git/dfc043b119213d80105c9e19991f0257a0d59a22).

Code-Review: +1; Should fix the protection issue that this bug is concerned with. Haven't tested.

Other things that are still likely broken, and should probably be fixed with a public followup patch:

• I note we might still lose non-log recentchanges entries that belong to the new page at the title rather than the old, deleted page since it deletes entries by both rc_namespace+rc_title and by rc_cur_id.
• The 'CategoryAfterPageRemoved' hook function (inside the call to WikiPage::updateCategoryCounts()) will effectively be called on the new page at the title rather than the old. WikiPage::updateCategoryCounts() itself should be fine.

@Anomie Will you create separate tickets for those items?

I also made https://gerrit.wikimedia.org/r/#/c/294099/ and will do the category hook fix once this patch is merged.

In T128624#2377132, @dpatrick wrote:

@Anomie Will you create separate tickets for those items?

Looks like Aaron already fixed them both.

Unmarking as security as it was mostly a regression (didn't affect 1.26 and below) and was already fixed publicly in master. Backported to 1.27 so it gets caught in the next release. I think this is resolved now?

Change 304107 merged by jenkins-bot:
Use the specified page ID for LinksDeletionUpdate

https://gerrit.wikimedia.org/r/304107