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

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.

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.

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!