Skip to content
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

Closed
switchupcb opened this issue Jul 7, 2023 · 14 comments
Closed

Gateway Rate Limit Reset Abuse Confirmation #6276

switchupcb opened this issue Jul 7, 2023 · 14 comments
Labels

Comments

@switchupcb
Copy link
Contributor

Description

The Gateway Rate Limiting documentation states the following information.

Apps can send 120 gateway events per connection every 60 seconds, meaning an average of 2 commands per second. Apps that surpass the limit are immediately disconnected from the Gateway. Similar to other rate limits, repeat offenders will have their API access revoked.

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

@switchupcb switchupcb added the bug label Jul 7, 2023
@switchupcb
Copy link
Contributor Author

switchupcb commented Jul 8, 2023

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:

@Zoddo
Copy link
Contributor

Zoddo commented Jul 8, 2023

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.

Please explain if using this behavior is considered abuse.

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):

You will not (and will not attempt to or permit or enable others to): [...] access or use the APIs in any way that [...] exceeds any API rate, call, or other usage limits we set in our sole discretion (including as set forth in the Developer Policy or the applicable Documentation) or that we believe constitutes excessive or abusive usage.

and the Developer Policy:

As described in the Developer Terms, Discord may set and enforce limits on your use of the APIs (for example, by limiting the number of API requests that you may make, the number of servers your Application is in, or the number of users you may serve) at our sole discretion. You agree to, and will not attempt to circumvent, such limitations documented with each API.

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".

@switchupcb
Copy link
Contributor Author

switchupcb commented Jul 8, 2023

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.

@switchupcb
Copy link
Contributor Author

switchupcb commented Jul 8, 2023

re: @Zoddo

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".

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:

  1. Hello, Identify, and Heartbeats count towards a "per session" Global Gateway rate limit.
  2. All Send Events count towards a "per session" Global Gateway rate limit.
  3. Followed by an implementation of a "per session" rate limit.

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.

@ooliver1
Copy link

ooliver1 commented Jul 8, 2023

Update: Stop looking at closed issues and do your work.

@switchupcb I watch this repository, so I see every update from here. This is not affecting my productivity.

name-calling (rude)

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.

@switchupcb
Copy link
Contributor Author

There is no name-calling here?
@ooliver1

#5557 (comment)
#5605 (reply in thread)

@switchupcb
Copy link
Contributor Author

The irony of @SuperSajuuk coming in here and downvoting all my posts.

This is what I'm talking about.

@ManHatos
Copy link
Contributor

ManHatos commented Jul 8, 2023

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.
I am not a Discord employee, not sure what work I haven't done

@switchupcb
Copy link
Contributor Author

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!!!

whbwa

@ooliver1
Copy link

ooliver1 commented Jul 8, 2023

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".

@Sharp-Eyes
Copy link

wawa is accurate self-reflection

@switchupcb
Copy link
Contributor Author

switchupcb commented Jul 8, 2023

Yes, every issue is "useless". My ego is super fragile. And no one can have fun on the internet.

image

DO YOUR DEVELOPMENT WORK!!!

@MinnDevelopment
Copy link
Contributor

@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.

@thesadru
Copy link

thesadru commented Jul 8, 2023

别照愚人的愚昧回答他,免得你像他一样。

@discord discord locked as too heated and limited conversation to collaborators Jul 8, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

7 participants