Page MenuHomePhabricator

Simultaneous configuring of pending changes and page protection fails to apply page protection
Closed, ResolvedPublic

Description

On two occasions, simultaneous configuration of page protection and pending changes has resulted in page protection generating a log entry, but not taking effect. The protection pages in question are:
https://en.wikipedia.org/w/index.php?title=Eurovision_Song_Contest_2019&action=protect (ineffective protection was set at 11:04, 9 March 2019)
https://en.wikipedia.org/w/index.php?title=Googol&action=protect (ineffective protection was set at 08:43, 16 March 2019)

As of the time of this report, the latter ineffective protection is still current.

Possible related cases have been discussed here:
https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=888017750#Should_this_edit_have_happened?

Event Timeline

Samsara created this task.Mar 16 2019, 10:47 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 16 2019, 10:47 AM

I confrm the Googol example at about 2019-03-16T13:42Z via the web UI. And I confirm it was "fixed" as of 14:10, probably thanks to DumbBOT's edit.

The database shows no protection currently set.

Poking at it with mwrepl, I find

anomie@mwmaint1002:~$ mwrepl enwiki
...
hphpd> $t = Title::newFromText( 'Googol' );
$t = Title::newFromText( 'Googol' );
hphpd> =$t->getRestrictions( 'edit' )
=$t->getRestrictions( 'edit' )
Array
(
    [0] => "autoconfirmed"
)

So it's definitely showing up as protected in the code.

anomie@mwmaint1002:~$ mwrepl enwiki
...
hphpd> $t = Title::newFromText( 'Googol' );
$t = Title::newFromText( 'Googol' );
hphpd> var_dump( $t );
var_dump( $t );
object(Title)#404 (32) {
...
  ["mRestrictions"]=>
  array(0) {
  }
  ["mOldRestrictions":protected]=>
  bool(false)
...
  ["mRestrictionsLoaded"]=>
  bool(false)
...
}

hphpd> $readLatest = DBAccessObjectUtils::hasFlags( 0, Title::READ_LATEST );
$readLatest = DBAccessObjectUtils::hasFlags( 0, Title::READ_LATEST );
hphpd> =$readLatest
=$readLatest
false
hphpd> $id = $t->getArticleId()
$id = $t->getArticleId()
hphpd> =$id
=$id
18994679
hphpd> $cache = MediaWiki\MediaWikiServices::getInstance()->getMainWANObjectCache();
$cache = MediaWiki\MediaWikiServices::getInstance()->getMainWANObjectCache();
hphpd> =$cache->get( $cache->makeKey( 'page-restrictions', $id, $t->getLatestRevID() ) );
=$cache->get( $cache->makeKey( 'page-restrictions', $id, $t->getLatestRevID() ) );
Array
(
    [1] => stdClass Object
        (
            [pr_type] => "edit"
            [pr_expiry] => "infinity"
            [pr_level] => "autoconfirmed"
            [pr_cascade] => "0"
        )

    [2] => stdClass Object
        (
            [pr_type] => "move"
            [pr_expiry] => "infinity"
            [pr_level] => "autoconfirmed"
            [pr_cascade] => "0"
        )

)

Seems like the WANObjectCache is somehow incorrectly getting populated from stale data when or after FlaggedRevs inserts its null revision.

aaron added a comment.Mar 16 2019, 5:54 PM

Seems like it might be T217649 (which should be re-titled itself).

T217469 had a patch deployed... Is the issue on this task fixed, also, maybe?

Is that just coincidence, or did the numbers get flipped by accident? 469 vs 649? Are you saying there are three related issues? Thanks for clarifying.

kchapman assigned this task to aaron.Mar 25 2019, 8:56 PM
kchapman moved this task from Inbox to Doing on the Performance-Team board.
aaron closed this task as Resolved.Mar 26 2019, 5:17 AM

T217469 had a patch deployed... Is the issue on this task fixed, also, maybe?

I'd reckon so.

T217469 had a patch deployed... Is the issue on this task fixed, also, maybe?

Ooops, yes, you're right, I meant T217649!