-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Gateway Rate Limit Reset Abuse Confirmation #6276
Comments
No one cares. Update: Stop looking at closed issues and do your work. People who are looking at closed issues and not doing their work: |
Do you mean by disconnecting and resuming on-purpose when being close to the rate limit to continue to send commands? This is definitely against both the Developer Terms of Service (2.b.c.iv):
and the Developer Policy:
I believe that the reason why this is documented as being "per connection" instead of "per session" is to clarify that commands sent out of a session (before a READY or a RESUME, like heartbeats) are still counted against the limit. They didn't document it that way to say "if this rate-limit bothers you, just disconnect and resume when hitting it lol". |
re: @Zoddo Using the API in this manner doesn't access the APIs in any way that exceeds any API rate, call, or other usage limits Discord has set. As you have stated, the rate limit is documented at "per connection": This language indicates that creating a new connection and adhering to its rate limit is valid. Disconnecting and resuming to a WebSocket Connection while sending less than 120 events per connection is adhering to the specified rate limits. So disconnecting and resuming to send more events per second is technically valid. This message isn't an endorsement of the identified behavior, but rather a clarification. |
re: @Zoddo
We can personally speculate why certain language is included in the documentation, but that doesn't change what is actually there. Do I believe that you should implement the identified behavior? No. Do I believe that there is a reason to keep said behavior for other purposes? Yes. And perhaps Discord has their own reason. I can't be the first person to identify this behavior: How many people have created Discord Bots at this point in time? Nothing stops Discord from being thorough in their documentation and indicating:
The current rate limit is purposefully "per connection", so it's implied that adherence to it can be described by the above behavior. I created this issue to ask about clarification, but then I remembered... When you ask for people to elaborate on certain topics in this repository, it results in emotional reactions (downvotes) and name-calling (rude). So I'm not going to do that: I have documented the behavior, but not engaged in it. Furthermore, there are too many factors a large bot would require to abuse this in a manner that effects Discord's uptime. |
@switchupcb I watch this repository, so I see every update from here. This is not affecting my productivity.
There is no name-calling here? It would be best to wait for a response from a Discord employee if any, instead of giving replies like these. |
|
The irony of @SuperSajuuk coming in here and downvoting all my posts. This is what I'm talking about. |
Not really sure why I've been mentioned here... I reacted because you closed the issue stating 'No one cares' when only 2 days have passed without an answer. People here wait for months sometimes to get [official] answers lol. |
Like I literally close the issue and then everyone starts replying to it. I don't care about the answer anymore and don't want the employees to "feel bad" (like in #5557) just because I asked for clarification about something. So I closed the issue. No one cared about this issue before the issue closed. Why do you care now? Do your development work. Stop looking at closed issues!!! |
Do what work may I ask? We are not Discord employees. It is a Saturday/Sunday too, 4pm PST for Discord too. Nobody replied as you were likely (and now obviously) expecting an official response, instead of "speculation". |
wawa is accurate self-reflection |
@SuperSajuuk your comments are really not necessary. Please try to avoid breaking the code of conduct with inappropriate and toxic comments. To everyone else in this thread, I would recommend discontinuing this exchange as there is no value in it whatsoever. This is really not the place for this kind of conversation, keep it professional and on topic. |
别照愚人的愚昧回答他,免得你像他一样。 |
Description
The Gateway Rate Limiting documentation states the following information.
The Gateway Rate Limit is confirmed to be per WebSocket Connection according to the following discussion:
This functionality allows the user to send an unlimited amount of events per second using the steps outlined in Steps to Reproduce.
Steps to Reproduce
Follow the steps outlined in Test Per Connection Gateway Rate Limit (59s Time Limit) from switchupcb/disgo#26 (comment).
Expected Behavior
Please explain if using this behavior is considered abuse.
Current Behavior
The application can send as many events per second as it wants (on the same Discord Session) without being immediately disconnected from the Gateway, provided that the WebSocket Connection is connected and disconnected. However, I'm unsure that all these send events are processed at once.
Screenshots/Videos
No response
Client and System Information
All
The text was updated successfully, but these errors were encountered: