Users may add behavior Behavior_DRAIN_OVER_LIMIT to the rate check request. A
GetRateLimits call drains the remaining counter on first over limit event. Then,
successive GetRateLimits calls will return zero remaining counter and not any
residual value. This behavior works best with token bucket algorithm
because the Remaining counter will stay zero after an over limit until reset
time, whereas leaky bucket algorithm will immediately update Remaining to a
non-zero value.
This facilitates scenarios that require an over limit event to stay over limit
until the rate limit resets. This approach is necessary if a process must make
two rate checks, before and after a process, and the Hit amount is not known
until after the process.
Before process: Call GetRateLimits with Hits=0 to check the value of
Remaining counter. If Remaining is zero, it's known
that the rate limit is depleted and the process can be aborted.
After process: Call GetRateLimits with a user specified Hits value. If
the call returns over limit, the process cannot be aborted because it had
already completed. Using DRAIN_OVER_LIMIT behavior, the Remaining count
will be drained to zero.
Once an over limit occurs in the "After" step, successive processes will detect
the over limit state in the "Before" step.
DRAIN_OVER_LIMIT.golangci-lintmake prototo build protobufs usingbuftool. See: https://buf.build/docs/Users may add behavior
Behavior_DRAIN_OVER_LIMITto the rate check request. AGetRateLimitscall drains the remaining counter on first over limit event. Then, successiveGetRateLimitscalls will return zero remaining counter and not any residual value. This behavior works best with token bucket algorithm because theRemainingcounter will stay zero after an over limit until reset time, whereas leaky bucket algorithm will immediately updateRemainingto a non-zero value.This facilitates scenarios that require an over limit event to stay over limit until the rate limit resets. This approach is necessary if a process must make two rate checks, before and after a process, and the
Hitamount is not known until after the process.GetRateLimitswithHits=0to check the value ofRemainingcounter. IfRemainingis zero, it's known that the rate limit is depleted and the process can be aborted.GetRateLimitswith a user specifiedHitsvalue. If the call returns over limit, the process cannot be aborted because it had already completed. UsingDRAIN_OVER_LIMITbehavior, theRemainingcount will be drained to zero.Once an over limit occurs in the "After" step, successive processes will detect the over limit state in the "Before" step.