Closed Bug 1051214 Opened 10 years ago Closed 10 years ago

double-check ratelimiting

Categories

(Input Graveyard :: Code Quality, defect, P1)

defect

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.
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.
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
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
Product: Input → Input Graveyard
You need to log in before you can comment on or make changes to this bug.