(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;

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

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

+---------+---------+----------+-----------+------------+
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_page	pr_type	pr_level	pr_expiry	pr_cascade

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

352339	edit		infinity	0
352339	move		infinity	0

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

Received through pastebin:

sql enwiki_p

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

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

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

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

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

+-------------------+
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.

"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.

(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='';
+----------+

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

+----------+
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.