We could do this by overriding IrcBot.send_line, although I'm not completely sure how to do this in an asyncio-friendly way. Obvious options are:

• a simple yield asyncio.sleep(time), or maybe BaseEventLoop.call_at. Might give issues with ordering and late PONG replies
• using a queue and getting a value from there every now and then is cleaner. We can even use a priority queue to make sure PONGs have priority. But I'm not immediately sure how to write the part that reads from the queue and hook that into the event loop.

We could implement the rate limit on the wikibugs.py side and only push something into redis every second? Yay hacks.

Change 238792 had a related patch set uploaded (by Legoktm):
Wait at least 1 second before pushing into redis

https://gerrit.wikimedia.org/r/238792

Change 238792 merged by jenkins-bot:
Wait at least 1 second before pushing into redis

https://gerrit.wikimedia.org/r/238792

So now someone needs to try a batch edit and we'll see if it floods off? :D

On Sept 17 (PDT):
[06:55:14] <-- wikibugs (tools.wiki@wikimedia/bot/pywikibugs) has quit (Excess Flood)

:|

That was for 19 tasks being edited, btw.

Worth bumping it up to two seconds and trying that out? Flooded off quite a few times today

Change 263931 had a related patch set uploaded (by Samtar):
Redis delay to 2 seconds

https://gerrit.wikimedia.org/r/263931

In T112032#1932995, @Samtar wrote:

Flooded off quite a few times today

My bad :) T123302

@greg '>.<

Change 263931 merged by jenkins-bot:
Bump redis delay to 2 seconds to avoid flooding

https://gerrit.wikimedia.org/r/263931

Let's try it...

I think it's working - wikibugs is going mad on -dev at the moment but the rate looks good and it's not being flooded off :D

@Samtar looks like you fixed it indeed. I saw mass edits that would have always kicked the bot in the past.. but it stayed online. very cool :)

So we can close this now?

I think freenode probably has two sets of limits, e.g. max x messages per 10 seconds, and max 5x messages per 5 minutes. Your bulk change might cause it to hit the latter.

@Luke081515 I think it's currently working the best it's going to - the current redis delay prevents all but absolutely massive jobs from causing fn to kick wikibugs. Perhaps the issue is now on what wikibugs actually notifies the channel of?

I think we can solve the actual issue: Figure out, which numbers of messages are allowed in 5 minutes, and we can solve this, if we count how many messages were send in the last minutes. The bug is not what wikibugs send, this was because herald was active, if you for example remove a CC, so you can not solve this by changing the thing which were shown by wikibugs.

This is still an issue nowadays. wikibugs just got kicked again for flooding after a mass edit on Phabricator.

See discussion in T237109:

So I think the rate limiting is largely working as intended; being disconnected in times of large numbers of messages is not a huge issue, and actually potentially beneficial (as messages remaining queued before and during the reconnect get dropped -- this prevents the bot from building up a potentially hours-long backlog).

16:36 -!- wikibugs [~wikibugs2@wikimedia/bot/pywikibugs] has quit [Excess Flood]