Closed
Bug 1051214
Opened 10 years ago
Closed 10 years ago
double-check ratelimiting
Categories
(Input Graveyard :: Code Quality, defect, P1)
Input Graveyard
Code Quality
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: willkg, Assigned: willkg)
Details
(Whiteboard: u=user c=feedback p=1 s=input.2014q3)
In the Graphite graphs, I see HTTP 429s being returned, but that graph doesn't line up with the throttled graph. Seems like we're returning HTTP 429s, but not statsd'ing the throttle rule that got tripped.
The ratelimit decorator seems to be working fine. The RatelimitThrottle might be buggy. Something is fishy.
Putting this in my queue to look at on Monday since it's related to rate limiting and I don't want to be limiting things that shouldn't be limited.
Assignee | ||
Comment 1•10 years ago
|
||
429s are only coming back from the API. I'm not seeing any statsd calls for API-related throttling.
I looked at the RatelimitThrottle code and reduced it a bit. That landed in:
https://github.com/mozilla/fjord/commit/8f0c36e935aa6b82141b12272881ef9799942262
I'm hoping that makes it more likely that it does statsd calls.
Assignee | ||
Comment 2•10 years ago
|
||
Making this a 2 pointer. I'll be working on this on and off over the next couple of days.
Whiteboard: u=user c=feedback p= s=input.2014q3 → u=user c=feedback p=2 s=input.2014q3
Assignee | ||
Comment 3•10 years ago
|
||
Bah. Turns out my dashboard wasn't up-to-date and thus wasn't seeing some of the throttled statsd calls.
Marking this as FIXED.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: u=user c=feedback p=2 s=input.2014q3 → u=user c=feedback p=1 s=input.2014q3
Updated•8 years ago
|
Product: Input → Input Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•