API reporting incorrect rate limit
Closed, ResolvedPublic

Description

Author: matthew.britton

Description:
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.


Version: unspecified
Severity: enhancement
URL: http://en.wikipedia.org/wiki/Wikipedia:VPR#Non-admin_rollbackers

bzimport added a project: MediaWiki-API.Via ConduitNov 21 2014, 10:02 PM
bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz12760.
bzimport created this task.Via LegacyJan 23 2008, 6:18 PM
FastLizard4 added a comment.Via ConduitMay 11 2008, 6:30 AM

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.

MER-C added a comment.Via ConduitMay 14 2008, 7:07 AM

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.

bzimport added a comment.Via ConduitMay 14 2008, 1:56 PM

ayg wrote:

There's no sane reason to have any limit at all given that any sysop can revoke the status at will.

MER-C added a comment.Via ConduitMay 16 2008, 7:21 AM

New discussion at [[Wikipedia:Village pump (proposals)#Non-admin rollbackers]].

bzimport added a comment.Via ConduitMay 20 2008, 8:02 PM

mattbisanz wrote:

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.

bzimport added a comment.Via ConduitMay 20 2008, 10:37 PM

J.delanoywiki wrote:

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.

bzimport added a comment.Via ConduitMay 22 2008, 12:07 AM

matthew.britton wrote:

Limit raised to 100 last night, apparently.

bzimport added a comment.Via ConduitMay 22 2008, 1:14 AM

compwhizii wrote:

(In reply to comment #7)

Limit raised to 100 last night, apparently.

Sweet! :)

MZMcBride added a comment.Via ConduitJun 9 2008, 10:31 PM

According to the API, the limit is 10 / min.

bzimport added a comment.Via ConduitJun 9 2008, 10:35 PM

mike.lifeguard+bugs wrote:

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.

bzimport added a comment.Via ConduitOct 11 2008, 3:29 AM

mike.lifeguard+bugs wrote:

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.

bzimport added a comment.Via ConduitOct 24 2008, 9:31 PM

matthew.britton wrote:

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.

bzimport added a comment.Via ConduitOct 24 2008, 9:40 PM

bugs wrote:

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

bzimport added a comment.Via ConduitOct 24 2008, 9:45 PM

matthew.britton wrote:

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

bzimport added a comment.Via ConduitOct 24 2008, 9:47 PM

mike.lifeguard+bugs wrote:

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

bzimport added a comment.Via ConduitOct 24 2008, 10:06 PM

bugs wrote:

(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. :-)

bzimport added a comment.Via ConduitOct 30 2008, 5:18 PM

matthew.britton wrote:

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

Catrope added a comment.Via ConduitOct 30 2008, 5:21 PM

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

bzimport added a comment.Via ConduitOct 30 2008, 5:23 PM

mike.lifeguard+bugs wrote:

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

MZMcBride added a comment.Via ConduitOct 31 2008, 12:46 AM

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.

Catrope added a comment.Via ConduitOct 31 2008, 12:03 PM

(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)?

MZMcBride added a comment.Via ConduitOct 31 2008, 4:32 PM

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.

Catrope added a comment.Via ConduitOct 31 2008, 4:36 PM

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

Catrope added a comment.Via ConduitNov 18 2008, 3:39 PM

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

bzimport added a comment.Via ConduitNov 18 2008, 3:44 PM

ayg wrote:

(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>
Catrope added a comment.Via ConduitNov 18 2008, 4:07 PM

Fixed in r43678. Group-specific rate limits were introduced after uiprop=ratelimits was added, and I must've overlooked it.

Add Comment