Page MenuHomePhabricator

Create a solution for organised editing activities and temporary account rate limiting
Open, Needs TriagePublic

Description

I was told by the organiser of T421305: Lift IP cap on 2026-03-27 for Senior Citizen Write Wikipedia course - cs.wikipedia that the participants were running into some kind of rate limitting. I reviewed the activity from the IP provided, and I found two temp account creations, each with one edit, and two other edits (from registered accounts), which shouldn't be considered a lot. However, it seems like we're throttling temporary accounts to "at most 1 per 10 minutes AND at most 6 per 24 hours", which was violated (the temp account creations are almost exactly 10 minutes from each other). This is confirmed by events in the throttler channel, see Logstash.

Entries in throttle.php can override the temp account limits. However, this only happens when the processing user defined the tempaccountvalue key. If only the value key is provided, the only thing that changes is the six account limit for named accounts, meaning temporary account edits are still heavily limited.

For events that have a six account limit exemption (as instructed in Meta-Wiki docs), we should probably lift both limits by default (if the IP has named account exemption, it should be also considered exempt for temporary account purposes). However, this might also generate problems in organised events that previously did not require throttle exemptions. I'm not sure what would be the solution for those.

Event Timeline

@kostajh @Tchanders @Niharika Wondering if you have thoughts on this. Would you have any objections if throttle-analyze.php would use value as tempaccountvalue, unless tempaccountvalue was explicitly set? (The code also uses a default of 50 for value if it is missing; I'd be open to revisiting that)

@kostajh @Tchanders @Niharika Wondering if you have thoughts on this. Would you have any objections if throttle-analyze.php would use value as tempaccountvalue, unless tempaccountvalue was explicitly set? (The code also uses a default of 50 for value if it is missing; I'd be open to revisiting that)

That sounds OK to me. Alternatively, we could make the documentation more clear in case both values need to be adjusted separately.