Page MenuHomePhabricator

Corrupt protections in page_restrictions table
Closed, ResolvedPublic

Description

The API is outputting that a particular page is protected when the protection log (and reality) indicate otherwise. This may be a Wikimedia issue and it may not be related to the API at all, but I filed it under MediaWiki / API anyway.

The API query is: http://en.wikipedia.org/w/api.php?action=query&prop=info&inprop=protection&titles=1755%20Lisbon%20earthquake

The protection log for the given title is: http://en.wikipedia.org/w/index.php?title=Special:Log&page=1755_Lisbon_earthquake

So perhaps one of the tables contains bad rows? Or the API has a glitch? The output from the API looks rather unusual:

<?xml version="1.0"?>
<api>

<query>
  <pages>
    <page pageid="352339" ns="0" title="1755 Lisbon earthquake" touched="2008-12-13T10:06:03Z" lastrevid="257482439" counter="1" length="21025">
      <protection>
        <pr type="edit" level="" expiry="infinity" />
        <pr type="move" level="" expiry="infinity" />
        <pr type="move" level="" expiry="infinity" />
        <pr type="edit" level="" expiry="infinity" />
      </protection>
    </page>
  </pages>
</query>

</api>


Version: unspecified
Severity: minor

Details

Reference
bz16629

Related Objects

StatusSubtypeAssignedTask
OpenNone
ResolvedNone

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:26 PM
bzimport set Reference to bz16629.
bzimport added a subscriber: Unknown Object (MLST).

(In reply to comment #0)

So perhaps one of the tables contains bad rows? Or the API has a glitch? The
output from the API looks rather unusual:

I think so. Could someone with toolserver access verify this with the following query (on enwiki)?

SELECT pr_page, pr_type, pr_level, pr_expiry, pr_cascade FROM page_restrictions WHERE pr_page=352339;

mzmcbride@nightshade:~$ sql enwiki_p

mysql> SELECT pr_page, pr_type, pr_level, pr_expiry, pr_cascade FROM page_restrictions

-> WHERE pr_page=352339;

+---------+---------+----------+-----------+------------+

pr_pagepr_typepr_levelpr_expirypr_cascade

+---------+---------+----------+-----------+------------+

352339editinfinity0
352339moveinfinity0

+---------+---------+----------+-----------+------------+
2 rows in set (0.00 sec)

(In reply to comment #2)

mzmcbride@nightshade:~$ sql enwiki_p

mysql> SELECT pr_page, pr_type, pr_level, pr_expiry, pr_cascade FROM
page_restrictions

-> WHERE pr_page=352339;

+---------+---------+----------+-----------+------------+

pr_pagepr_typepr_levelpr_expirypr_cascade

+---------+---------+----------+-----------+------------+

352339editinfinity0
352339moveinfinity0

+---------+---------+----------+-----------+------------+
2 rows in set (0.00 sec)

Received through pastebin:

sql enwiki_p

mysql> SELECT COUNT(*) FROM page_restrictions WHERE pr_level='';
+----------+

COUNT(*)

+----------+

3414

+----------+
1 row in set (0.99 sec)

mysql> SELECT page_restrictions FROM page WHERE page_id=352339;
+-------------------+

page_restrictions

+-------------------+

move=:edit=

+-------------------+
1 row in set (0.00 sec)

mysql>

(In reply to comment #3)

mysql> SELECT COUNT(*) FROM page_restrictions WHERE pr_level='';
+----------+

COUNT(*)

+----------+

3414

+----------+
1 row in set (0.99 sec)

So there are probably 1707 pages with corrupted protections like these.

mysql> SELECT page_restrictions FROM page WHERE page_id=352339;
+-------------------+

page_restrictions

+-------------------+

move=:edit=

+-------------------+
1 row in set (0.00 sec)

This is also corrupted, and causes the other two entries in the API output.

Changing summary and component accordingly.

brion added a comment.Dec 23 2008, 2:30 AM

"move=:edit=" is perfectly legit in page.page_restrictions, and is just the old way of indicating that move and edit are both not restricted. If the API is misinterpreting them, that's probably wrong.

The page_restrictions table entries, however, do seem bogus. If there's remaining migration code that's mis-migrating these, it needs to be fixed not to save the extra entries.

I'm currently running a batch job to clear them out...

(In reply to comment #6)

"move=:edit=" is perfectly legit in page.page_restrictions, and is just the old
way of indicating that move and edit are both not restricted. If the API is
misinterpreting them, that's probably wrong.

OK, I'll fix that.

aaron added a comment.Dec 29 2008, 7:28 PM

(In reply to comment #6)

"move=:edit=" is perfectly legit in page.page_restrictions, and is just the old
way of indicating that move and edit are both not restricted. If the API is
misinterpreting them, that's probably wrong.

The page_restrictions table entries, however, do seem bogus. If there's
remaining migration code that's mis-migrating these, it needs to be fixed not
to save the extra entries.

I'm currently running a batch job to clear them out...

Is this done?

Yes, the first part was done (running the maintenance script on WMF's tables).

From the Toolserver sql enwiki_p today:

mysql> SELECT COUNT(*) FROM page_restrictions WHERE pr_level='';
+----------+

COUNT(*)

+----------+

0

+----------+
1 row in set (0.02 sec)

The second part is still (as far as I'm aware) unresolved. Just waiting on Roan to commit some pretty code. :-)

(In reply to comment #9)

The second part is still (as far as I'm aware) unresolved. Just waiting on Roan
to commit some pretty code. :-)

Done in r45675.