Last modified: 2008-11-18 16:07:20 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T14760, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 12760 - API reporting incorrect rate limit
API reporting incorrect rate limit
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
unspecified
All All
: Normal enhancement with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/wiki/Wikipedi...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-23 18:18 UTC by Gurch
Modified: 2008-11-18 16:07 UTC (History)
9 users (show)

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


Attachments

Description Gurch 2008-01-23 18:18:12 UTC
Currently members of the rollbacker group on the English Wikipedia are limited to 5 rollbacks per minute, presumably to prevent abuse.

Unfortunately, this rate really isn't high enough, and is regularly exceeded while trying to deal with vandalism on the English Wikipedia during busy periods. I could understand such a limit being necessary if rollback was available to all autoconfirmed users, but since it is given out on the English Wikipedia only to individual users at the discretion of administrators, and can be removed again at the first sign of misuse, the potential for abuse seems much lower.

It would be nice if the limit could be raised to a level where it does not interfere with its legitimate use by the group of people which it is intended to benefit. Doubling the limit to 10 edits per minute, or doing away with it altogether, would achieve this.
Comment 1 Andrew "FastLizard4" Adams 2008-05-11 06:30:48 UTC
I would support any increase to 10 or above (perhaps to no limit).  I frequently hit the 5 rev/min cap while reverting vandalism using Huggle when vandalism rates are high, and it greatly slows down the process.
Comment 2 MER-C 2008-05-14 07:07:26 UTC
See discussion on this issue at [[Wikipedia:Village pump (technical)#Non-admin rollbackers]]. Also changed the title to more accurately reflect the wishes here and at VPT.
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-05-14 13:56:16 UTC
There's no sane reason to have any limit at all given that any sysop can revoke the status at will.
Comment 4 MER-C 2008-05-16 07:21:42 UTC
New discussion at [[Wikipedia:Village pump (proposals)#Non-admin rollbackers]].
Comment 5 MBisanz 2008-05-20 20:02:20 UTC
It would appear that there is no significant opposition to the idea (Note:I supported it so I'm biased).  So I guess now it would be up to the developers having the time to code the solution, test it, and roll it out. 
Comment 6 J.delanoy 2008-05-20 22:37:14 UTC
The straw poll at [[WP:VPR#Straw Poll c]] indicated that there was no opposition whatsoever to at least upping the limit and nearly all participants supported removing the limit entirely.
Comment 7 Gurch 2008-05-22 00:07:34 UTC
Limit raised to 100 last night, apparently.
Comment 8 John 2008-05-22 01:14:11 UTC
(In reply to comment #7)
> Limit raised to 100 last night, apparently.
> 

Sweet! :)
Comment 9 MZMcBride 2008-06-09 22:31:44 UTC
According to the API, the limit is 10 / min.
Comment 10 Mike.lifeguard 2008-06-09 22:35:39 UTC
en.wikibooks had 20/min at one point, and the general feeling was this was too low still, so 10/min is really not ok. Removing the rate limit for wikis where rollback is explicitly granted seems reasonable. (Are there wikis where you get it on autoconfirmed or something?) If we're choosing who to allow access to the tool, then the rate limit seems redundant.
Comment 11 Mike.lifeguard 2008-10-11 03:29:34 UTC
On noc I currently see:
        // For expanded rollback permissions...
        'rollback' => array(
            'user' => array( 10, 60 ), // was array( 5, 60 ), -- brino 2008-05-15
            'newbie' => array( 5, 120 ),
            // practicality has won out over paranoia on enwiki, raising from 20 to 100 -- TS 2008-05-21
            'rollbacker' => array( 100, 60 ),

However, for wikis giving +rollback explicitly (enwikibooks for example) no rate limit for rollbackers would be better - we're choosing them to make good use of the tool not giving it out willy nilly.
Comment 12 Gurch 2008-10-24 21:31:37 UTC
Resolving this since my original request has been fulfilled and while not infinite, 100 actions per minute is sufficiently high that realistically nobody will be affected by it.
Comment 13 Casey Brown 2008-10-24 21:40:06 UTC
(In reply to comment #11)
> On noc I currently see:

IIRC, noc is terribly out-of-date and should not be relied on. (I think Tim said that one... but don't quote him. ;-))
Comment 14 Gurch 2008-10-24 21:45:05 UTC
(In reply to comment #13)
> IIRC, noc is terribly out-of-date and should not be relied on. (I think Tim
> said that one... but don't quote him. ;-))

http://noc.wikimedia.org/conf/

"The files are dynamically generated and are perfectly up-to-date." seems to answer that. It could be lying, but I found a "2008-10-06" timestamp in one of the files, so it can't be that out of date.
Comment 15 Mike.lifeguard 2008-10-24 21:47:43 UTC
(In reply to comment #13)
> (In reply to comment #11)
> > On noc I currently see:
> 
> IIRC, noc is terribly out-of-date and should not be relied on. (I think Tim
> said that one... but don't quote him. ;-))
> 

noc gives live files now, IIRC

(In reply to comment #12)
> Resolving this since my original request has been fulfilled and while not
> infinite, 100 actions per minute is sufficiently high that realistically nobody
> will be affected by it.
> 

I was affected by this limit regularly until noratelimit was added to the global rollback group; this is still a problem for those who have non-admin rollback locally, so I'm re-opening this. That said, I'm open to the suggestion that this should be determined on a per-wiki basis, in which case I'll submit configuration requests to replace this.
Comment 16 Casey Brown 2008-10-24 22:06:40 UTC
(In reply to comment #14)
> (In reply to comment #13)
> > IIRC, noc is terribly out-of-date and should not be relied on. (I think Tim
> > said that one... but don't quote him. ;-))
> 
> http://noc.wikimedia.org/conf/
> 
> "The files are dynamically generated and are perfectly up-to-date." seems to
> answer that. It could be lying, but I found a "2008-10-06" timestamp in one of
> the files, so it can't be that out of date.
> 

That shows how long it's been since I've been on noc. :-)
Comment 17 Gurch 2008-10-30 17:18:44 UTC
(In reply to comment #15)
> I was affected by this limit regularly until noratelimit was added to the
> global rollback group.

You can read diffs and verify that they do indeed need to be reverted at a rate of more than 100 per minute? Where do we apply to have you do full time recent changes patrol on en.wikipedia, you would make everyone else obsolete.

Comment 18 Roan Kattouw 2008-10-30 17:21:00 UTC
(In reply to comment #17)
> (In reply to comment #15)
> > I was affected by this limit regularly until noratelimit was added to the
> > global rollback group.
> 
> You can read diffs and verify that they do indeed need to be reverted at a rate
> of more than 100 per minute?
Rolling back lots of revisions at once can actually be useful when a vandal mass-vandalizes stuff.
Comment 19 Mike.lifeguard 2008-10-30 17:23:05 UTC
(In reply to comment #17)
> (In reply to comment #15)
> > I was affected by this limit regularly until noratelimit was added to the
> > global rollback group.
> 
> You can read diffs and verify that they do indeed need to be reverted at a rate
> of more than 100 per minute? Where do we apply to have you do full time recent
> changes patrol on en.wikipedia, you would make everyone else obsolete.
> 

Gurch, there's no need to be rude.

Regardless, flood vandalism is common on small wikis. Luckily I'm no longer affected by this rate limit there. Nonetheless, one would think solving this for local rollback groups would make sense.

If this particular bug isn't going to get addressed, it should be closed again, and I will make a configuration request for my home wiki separately.
Comment 20 MZMcBride 2008-10-31 00:46:44 UTC
I think there's some confusion here. The limit was allegedly raised to 100 / min, but either the API is misreporting the limits or the rollback right is ignoring the configuration line. For somebody in the rollbacker group on en.wiki as of today, this is the result:

http://en.wikipedia.org/w/api.php?action=query&meta=userinfo&uiprop=ratelimits

      <ratelimits>
        <move>
          <user hits="8" seconds="60" />
        </move>
        <emailuser>
          <user hits="200" seconds="86400" />
        </emailuser>
        <rollback>
          <user hits="10" seconds="60" />
        </rollback>
      </ratelimits>

That clearly states that 10 rollbacks are allowed every 60 seconds. So there's obviously some type of bug here.
Comment 21 Roan Kattouw 2008-10-31 12:03:38 UTC
(In reply to comment #20)
> I think there's some confusion here. The limit was allegedly raised to 100 /
> min, but either the API is misreporting the limits or the rollback right is
> ignoring the configuration line. For somebody in the rollbacker group on
> en.wiki as of today, this is the result:
> 
> http://en.wikipedia.org/w/api.php?action=query&meta=userinfo&uiprop=ratelimits
> 
>       <ratelimits>
>         <move>
>           <user hits="8" seconds="60" />
>         </move>
>         <emailuser>
>           <user hits="200" seconds="86400" />
>         </emailuser>
>         <rollback>
>           <user hits="10" seconds="60" />
>         </rollback>
>       </ratelimits>
> 
> That clearly states that 10 rollbacks are allowed every 60 seconds. So there's
> obviously some type of bug here.
> 

Could you verify that the limit actually is higher than 10 rollbacks per minute (e.g. by trying to rollback 20 edits in the same minute)?
Comment 22 MZMcBride 2008-10-31 16:32:53 UTC
Using an autoconfirmed account in the rollbacker group on en.wiki I was able to rollback more than 10 edits in a minute. (See <http://en.wikipedia.org/w/index.php?title=Special:Contributions&offset=20081101000000&limit=17&target=Mzmcbride>.)

This indicates that it is the API that is misreporting here. I've removed the shell keyword. I suppose I could / should file a new bug, but meh.
Comment 23 Roan Kattouw 2008-10-31 16:36:16 UTC
(In reply to comment #22)
> Using an autoconfirmed account in the rollbacker group on en.wiki I was able to
> rollback more than 10 edits in a minute. (See
> <http://en.wikipedia.org/w/index.php?title=Special:Contributions&offset=20081101000000&limit=17&target=Mzmcbride>.)
> 
> This indicates that it is the API that is misreporting here. I've removed the
> shell keyword. I suppose I could / should file a new bug, but meh.
> 

I'll look into it.
Comment 24 Roan Kattouw 2008-11-18 15:39:49 UTC
(In reply to comment #23)
> (In reply to comment #22)
> > Using an autoconfirmed account in the rollbacker group on en.wiki I was able to
> > rollback more than 10 edits in a minute. (See
> > <http://en.wikipedia.org/w/index.php?title=Special:Contributions&offset=20081101000000&limit=17&target=Mzmcbride>.)
> > 
> > This indicates that it is the API that is misreporting here. I've removed the
> > shell keyword. I suppose I could / should file a new bug, but meh.
> > 
> 
> I'll look into it.
> 

I did, and it works fine for me: on MW.org I'm a sysop and consequently have no rate limits at all, on enwiki I'm not a sysop and I get the exact same ratelimits listed in comment #20. This leads me to think the reported must've been logged out while querying meta=userinfo. To be sure, please have someone in the rollbacker group (but not in the sysop group!) run the following API query:

http://en.wikipedia.org/w/api.php?action=query&meta=userinfo&uiprop=ratelimits|groups

If the result indicates the user is in the rollbacker group *and* lists the rate limits for anons, please REOPEN.
Comment 25 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-11-18 15:44:56 UTC
(In reply to comment #24)
> I did, and it works fine for me: on MW.org I'm a sysop and consequently have no
> rate limits at all, on enwiki I'm not a sysop and I get the exact same
> ratelimits listed in comment #20. This leads me to think the reported must've
> been logged out while querying meta=userinfo. To be sure, please have someone
> in the rollbacker group (but not in the sysop group!) run the following API
> query:
> 
> http://en.wikipedia.org/w/api.php?action=query&meta=userinfo&uiprop=ratelimits|groups
> 
> If the result indicates the user is in the rollbacker group *and* lists the
> rate limits for anons, please REOPEN.

I'm in the rollbacker group but not a sysop on enwiki, and I get 10 rollbacks a second listed:

      <ratelimits>
        <move>
          <user hits="8" seconds="60" />
        </move>
        <emailuser>
          <user hits="200" seconds="86400" />
        </emailuser>
        <rollback>
          <user hits="10" seconds="60" />
        </rollback>
      </ratelimits>
Comment 26 Roan Kattouw 2008-11-18 16:07:20 UTC
Fixed in r43678. Group-specific rate limits were introduced after uiprop=ratelimits was added, and I must've overlooked it.

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


Navigation
Links