Last modified: 2009-01-12 14:27:47 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 16629 - Corrupt protections in page_restrictions table
Corrupt protections in page_restrictions table
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal minor (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 16660
  Show dependency treegraph
 
Reported: 2008-12-13 13:59 UTC by MZMcBride
Modified: 2009-01-12 14:27 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description MZMcBride 2008-12-13 13:59:51 UTC
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>
Comment 1 Roan Kattouw 2008-12-14 15:44:51 UTC
(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;
Comment 2 MZMcBride 2008-12-14 17:52:18 UTC
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)
Comment 3 Roan Kattouw 2008-12-14 18:07:26 UTC
(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='';
+----------+
| 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> 
Comment 4 Roan Kattouw 2008-12-14 18:08:57 UTC
(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.
Comment 5 Roan Kattouw 2008-12-14 18:09:51 UTC
Changing summary and component accordingly.
Comment 6 Brion Vibber 2008-12-23 02:30:32 UTC
"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...
Comment 7 Roan Kattouw 2008-12-23 10:36:33 UTC
(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.
Comment 8 Aaron Schulz 2008-12-29 19:28:23 UTC
(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?
Comment 9 MZMcBride 2008-12-29 19:32:56 UTC
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. :-)
Comment 10 Roan Kattouw 2009-01-12 14:27:47 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links