Skip to content

Fix rate limiter window reset and usage timing in GatewayRatelimiter #10213

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 4 commits into from

Conversation

shashankpandey04
Copy link

@shashankpandey04 shashankpandey04 commented Jun 20, 2025

Summary

This pull request improves the internal logic of the GatewayRatelimiter to ensure more accurate and consistent rate-limiting behavior.
Key Fixes:

  • The rate-limit window (self.window) and token count (self.remaining) now reset together, preventing desync issues.
  • The rate-limit window now starts when the first token is consumed, ensuring correct delay calculations.

Why it matters:
Previously, if the rate-limit window was not reset properly while remaining was, the calculated delay could be incorrectly zero, causing shards to reconnect instantly without actually waiting for the rate limit to reset. This could result in:
This could result in:

  • Unintentional rate-limit violations
  • Gateway errors or Reconnects
  • Unstable shard behavior
    This fix ensures the shards respect the intended cooldown window, improving overall stability and compliance with Discord’s Gateway rate limits.

Checklist

  • If code changes were made then they have been tested.
    • I have updated the documentation to reflect the changes.
  • This PR fixes an issue.
  • This PR adds something new (e.g. new method or parameters).
  • This PR is a breaking change (e.g. methods or parameters removed/renamed)
  • This PR is not a code change (e.g. documentation, README, ...)

Sorry, something went wrong.

@shashankpandey04
Copy link
Author

shashankpandey04 commented Jun 20, 2025

For those who didn't understand the para I have a shorter summary for you
The rate limiter was resetting the remaining requests, but not updating the timer (window) properly. So shards could think the rate limit expired and reconnect instantly, even though they were still supposed to wait. 🕺
When the window expires (current > window + per), only remaining was reset. But self.window was only reset if remaining == max, which might not happen immediately...especially under race conditions or rapid reconnect attempts (which is exactly what's happening in my case).
For example, if Bot X has 30 shards and they all get rate-limited, the bot starts retrying to connect those shards without waiting, causing an infinite reconnect cycle...until the rate limit is finally lifted.

shashankpandey04 and others added 3 commits June 21, 2025 08:24
@Rapptz
Copy link
Owner

Rapptz commented Jun 26, 2025

I don't believe this fix to be correct. Was this written with AI or something?

Each shard gets its own gateway implementation which has its own rate limit state. Not to mention that the only way to trigger a rate limit is by sending a gateway message. These are currently restricted to essentially requesting chunks or doing a presence update request. Its relevance when it comes to reconnecting is unclear. What exactly is the issue you're facing?

@shashankpandey04
Copy link
Author

Closing this PR — after further testing, the rate limiting turned out to be caused by API-heavy startup tasks on our end, not an issue with the library itself.

And just to clarify — my change wasn’t AI-written. I debugged this issue manually and edited what I thought matched the symptoms we were facing. Appreciate the feedback either way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants