-
-
Notifications
You must be signed in to change notification settings - Fork 607
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
ratelimits: Use INCRBY instead of SET when a bucket already exists #7782
Conversation
@jprenken, this PR appears to contain configuration and/or SQL schema changes. Please ensure that a corresponding deployment ticket has been filed with the new values. |
@jprenken, this PR adds one or more new feature flags: IncrementRateLimits. As such, this PR must be accompanied by a review of the Let's Encrypt CP/CPS to ensure that our behavior both before and after this flag is flipped is compliant with that document. Please conduct such a review, then add your findings to the PR description in a paragraph beginning with "CPS Compliance Review:". |
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.
Looks good to me. A couple of optional quibbles on comments.
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.
Looks good, will approve again when tests pass.
Add a new method,
BatchIncrement
, to issueIncrBy
(instead ofSet
) to Redis. This helps prevent the race condition that allows bursts of near-simultaneous requests to, effectively, spend the same token.Call this new method when incrementing an existing key. New keys still need to use
BatchSet
because Redis doesn't have a facility to, within a single operation, increment or set a default value if none exists.Add a new feature flag,
IncrementRateLimits
, gating the use of this new method.CPS Compliance Review: This feature flag does not change any behaviour that is described or constrained by our CP/CPS. The closest relation would just be API availability in general.
Fixes #7780