You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
bug #51666 [RateLimiter] CompoundLimiter was accepting requests even when some limiters already consumed all tokens (10n)
This PR was merged into the 6.3 branch.
Discussion
----------
[RateLimiter] CompoundLimiter was accepting requests even when some limiters already consumed all tokens
| Q | A
| ------------- | ---
| Branch? | 6.3
| Bug fix
8000
? | yes
| New feature? | no
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | -
CompoundLimiter is accepting requests when the limit was reached previously.
When processing the limiters and the first one consumes exactly all the remaining tokens (remaining=0, accepted=true) and the next one already reached the limit previously (remaining=0, accepted=0) the $minimalRateLimit is considered the first one that will accept the request (even if it's not the most restrictive).
For example:
CompoundLimiter includes 2 limiters:
- limiter 1 - remaining 2 tokens
- limiter 2 - remaining 0 tokens
After consuming 2 tokens each each limiter generates to limits:
- `limiter1`->consume(2), generates a limit indicating `0` remaining tokens, **accepts** the request (it was last permitted)
- `limiter2`->consume(2), generates a limit indicating `0` remaining tokens, **did not accept** the request (it did not have 2 tokens to satisfy the request)
Because both of them have at this moment `0` remaining tokens, the minimum limit that is returned will be the limit from the `limiter1` . This means that the CompundLimiter will accept the request, even if the `limiter2` should be more restrictive.
If we switch the order in the constructor, the request will be denied. The order should not matter.
Commits
-------
65ce7f8 [RateLimiter] CompoundLimiter was accepting requests even when some limiters already consumed all tokens
0 commit comments