-
Notifications
You must be signed in to change notification settings - Fork 99
Fix global behavior #216
Fix global behavior #216
Changes from all commits
a48a45d
18b14db
2e0648a
f95acfd
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -405,9 +405,23 @@ func (s *V1Instance) getGlobalRateLimit(ctx context.Context, req *RateLimitReq) | |
// Global rate limits are always stored as RateLimitResp regardless of algorithm | ||
rl, ok := item.Value.(*RateLimitResp) | ||
if ok { | ||
// In the case we are not the owner, global behavior dictates that we respond with | ||
// what ever the owner has broadcast to use as the response. However, in the case | ||
// of TOKEN_BUCKET it makes little sense to wait for the owner to respond with OVER_LIMIT | ||
// if we already know the remainder is 0. So we check for a remainder of 0 here and set | ||
// OVER_LIMIT only if there are actual hits and this is not a RESET_REMAINING request and | ||
// it's a TOKEN_BUCKET. | ||
// | ||
// We cannot preform this for LEAKY_BUCKET as we don't know how much time or what other requests | ||
// might have influenced the leak rate at the owning peer. | ||
// (Maybe we should preform the leak calculation here?????) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As a newbie to this codebase, this comment suggests that we are breaking the single responsibility principle and we need to move this elsewhere. My thought was that we need a new API called There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 100% agree with this, as I had the exact same thought. However, I'm planning on removing GRPC so I decided to wait for a future PR. I could be convinced otherwise! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would avoid major refactors that are outside the context of this PR, for which I consider to be a bugfix. A follow up might make sense though. |
||
if rl.Remaining == 0 && req.Hits > 0 && !HasBehavior(req.Behavior, Behavior_RESET_REMAINING) && | ||
req.Algorithm == Algorithm_TOKEN_BUCKET { | ||
rl.Status = Status_OVER_LIMIT | ||
} | ||
return rl, nil | ||
} | ||
// We get here if the owning node hasn't asynchronously forwarded it's updates to us yet and | ||
// We get here if the owning node hasn't asynchronously forwarded its updates to us yet and | ||
// our cache still holds the rate limit we created on the first hit. | ||
} | ||
|
||
|
@@ -569,11 +583,9 @@ func (s *V1Instance) getLocalRateLimit(ctx context.Context, r *RateLimitReq) (_ | |
} | ||
|
||
metricGetRateLimitCounter.WithLabelValues("local").Inc() | ||
|
||
// If global behavior and owning peer, broadcast update to all peers. | ||
// Assuming that this peer does not own the ratelimit. | ||
// If global behavior, then broadcast update to all peers. | ||
if HasBehavior(r.Behavior, Behavior_GLOBAL) { | ||
s.global.QueueUpdate(r) | ||
s.global.QueueUpdate(r, resp) | ||
} | ||
|
||
return resp, nil | ||
|
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.
Instead of hardcoding the algorithm here you can do something like
And you can remove the other test (assuming that everything else is the same)
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.
I think it makes sense to keep the tests split personally for clarity but its a good point that we could merge if we expect the results to always be the same
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.
Always avoid DRY in tests, functional tests should be clear and verbose, and should generally not change once written.