-
-
Notifications
You must be signed in to change notification settings - Fork 520
Support category-based rate limiting #1336
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
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1336 +/- ##
==========================================
+ Coverage 98.08% 98.71% +0.63%
==========================================
Files 208 114 -94
Lines 9173 5538 -3635
==========================================
- Hits 8997 5467 -3530
+ Misses 176 71 -105
Continue to review full report at Codecov.
|
jan-auer
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! Please see the comments below. There is one request for change in the code checking for cached limits, and a few suggestions and clarifying questions.
sentry-ruby/spec/sentry/transport/http_transport_rate_limiting_spec.rb
Outdated
Show resolved
Hide resolved
If Sentry's 200 responses also contain rate limit related headers, we should store and update the SDK's rate limits like we see them in 429 responses. The only difference is that when receiving 429 responses the SDK should add default 60s delay to all event categories, which must not happen to 200 responses.
Sentry rate limits different types of events. And when rate limiting is enabled, it sends back a
429response to the SDK. Currently, the SDK would then raise an error like this:This change improves the SDK's handling on such responses by:
Closes #1072