Increase delay less aggressively on rate limit #419
Conversation
Immediately jumping to 6000-6500ms delays just because that's how long the API makes you wait after a bunch of quicker deletions is unnecessarily aggressive.
|
Am I correct in saying that this just increases the delay by a hardcoded 50 milliseconds and completely ignores the rate limit amount coming from Discord's API? |
|
Yes, but it will eventually keep adding on further 50ms delays if you still keep getting hit with rate limits, then it will stop around 2000-2500ms in my experience, which is definitely much faster than the 6000-6500ms it kicks you to normally (which really only happens because the initial delay was way too short). Do note that it still waits |
|
The API definitely rate limits you longer than necessary, but I wonder if we can for example add a fraction of the APIs indicated delay to the current delay instead of relying on getting rate limited many times in a row, which could necessitate a longer delay and might increase the likelihood of users getting banned for automating user accounts. |
|
Yeah, or maybe make the one-off cool-off delay longer, I don't know. |
|
The rate limit wait response should only determine cool down time and not be used to adjust the The current implementation will even lower the delete delay in some cases. For example:
|
Yes you are correct, this used to work because the cooldowns used to be way less aggressive. This approach of adding 50ms seems fine, but I fear if you're to far from what discord considers ok and you get multiple cooldowns in sequence, that could result in a more severe penalty. Has anyone confirmed if this approach is working? |
|
I'm not sure this is the full solution as the main issue is the API rate limit is too easy to trigger on mass operations because the initial search and delete delays are not sufficiently long. Perhaps this in combination with upping the default search delay to at least 500 and the default delete delay to at least 1500. I've never had it run successfully with lower timed defaults. |
In some limited testing search delay really didn't seem to matter all that much. Delete delay seems much more impactful and I've found that 2000 ms is really the safer margin. Often enough 1500 ms won't even get you through that many messages before rate limiting. There's currently an open PR (#402) to address this. If you indeed find yourself getting rate limited more often with the default search delay of 100 ms please post your findings! |
victornpb
added
the
PR outdated / needs rebase
Immediately jumping to 6000-6500ms delays just because that's how long the API makes you wait after a bunch of quicker deletions is unnecessarily aggressive.