sentry
sentry copied to clipboard
getsentry
Provide a status text containing the reason for HTTP 429
Problem Statement
Our backend returns an HTTP error 429 when some rate limit/quota of our public API is reached. There is no more information about the reason.
Solution Brainstorm
Return a status text that contains information about which rate limit was reached.
@danielkhan can you elaborate what you're seeing and provide full response headers and data?
The 429 is returned from the API when a rate limit is met and it lacks an error text that explains the real reason.
I don't have an example, just users requesting help on this.
in an offline discussion it turned out this is about API calls to Sentry (/api/0/), not store API calls (/api/n/). This probably warrants broader discussion in #discuss-api but as far as assigning teams for triage goes, I suppose either S&S or ecosystem is it?
I can improve the message in the error, but in the meantime, rate limit usage details are in the headers.
@AniketDas-Tekky can you provide an example of what this would look like? If we document this (if it isn't yet) and let support know, this might be good enough.
Seems like this is actually documented at https://docs.sentry.io/api/ratelimits/
On Thu, Aug 4, 2022 at 10:42 AM Daniel Khan @.***> wrote:
@AniketDas-Tekky https://github.com/AniketDas-Tekky can you provide an example of what this would look like? If we document this (if it isn't yet) and let support know, this might be good enough.
— Reply to this email directly, view it on GitHub https://github.com/getsentry/sentry/issues/37103#issuecomment-1204949476, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGMPRMT7IVNLVV4WRIWCCLVXN65TANCNFSM54Y7RW6Q . You are receiving this because you are on a team that was mentioned.Message ID: @.***>
This seems to apply to regular rate limits but what if a customer is over quota?
@danielkhan We have two APIs: The APIs sdks talk to to submit data (/api/123/{store,envelope}/ where 123 is the project id, served by Relay), and the APIs the web UI (and scripts cobbled together by customers) uses to query data (/api/0/).
the rate limits concerning any path under /api/0/ have nothing to do with what the user pays for and are only there to protect our infrastructure from greater harm. It's not possible to submit any crash reports using any endpoint starting with /api/0/.
If you run out of transactions, errors or attachment quota, we will start rate limiting requests under /api/123/.
Which API are we talking about? Typically when ppl talk about "the API" they mean /api/0, if they mean /api/123 it's typically called "ingest API" or "store endpoint(s)"
@untitaker, this was the original discussion where a user uses Node with tracing and sees 429. That's all we know and a symptom of the problem is that we can't tell the user where to look next.
We also had another request where a user would see the errors in the JavaScript console of the browser. Again, we either don't report the cause properly or support does not know which next step they should suggest to the user.
I thought providing an error text in the payload whenever a 429 occurs would be a pragmatic solution.
okay, I'm unassigning ecosystem from this for now because this customer request is about sdk requests, not "the API" as we typically call the endpoints we use for querying data.
Just had a customer report a mysterious 429 with no way to debug. Admin/stats_v2 has nothing so presumably load balancer.
Reopening as the original request has not been really resolved (fix just added same generic message + link to docs regardless of reason).
There is no more information about the reason. Return a status text that contains information about which rate limit was reached.
