Fix availablePermits() returning value greater than rate after release() and expiration - #7334
Open
angus-guo wants to merge 1 commit into
Open
Fix availablePermits() returning value greater than rate after release() and expiration#7334angus-guo wants to merge 1 commit into
angus-guo wants to merge 1 commit into
Conversation
angus-guo
force-pushed
the
fix/available-permits-clamp-to-rate
branch
from
August 30, 2026 17:11
607145d to
51a519a
Compare
likerhythm
added a commit
to likerhythm/redisson-lab
that referenced
this pull request
Sep 1, 2026
…rmitsAsync() 테스트 버전(배포 버전X) 기존 배포 버전을 사용하고 싶다면 이 클래스를 전체 주석처리하면 됨. 관련 Issue: redisson/redisson#7329 관련 PR: redisson/redisson#7334
angus-guo
force-pushed
the
fix/available-permits-clamp-to-rate
branch
from
September 2, 2026 13:16
51a519a to
d253420
Compare
…e() and expiration When a permit is released and later expires from the sorted set, availablePermitsAsync would add the released amount twice: once by release() (which clamps to rate), and again when the expired entry is counted. The second addition had no clamp, so currentValue could exceed the configured rate and be returned to the caller and persisted. releaseAsync() already clamps with 'if newValue > tonumber(rate) then newValue = rate'. This applies the same clamp to availablePermitsAsync after adding expired permits. The existing testRelease() passes because it runs so fast that no permits reach the expiration point; the new regression tests sleep past the interval to trigger the double-counting path. Fixes redisson#7329 Signed-off-by: angus-guo <217034332+angus-guo@users.noreply.github.com>
angus-guo
force-pushed
the
fix/available-permits-clamp-to-rate
branch
from
September 7, 2026 16:08
d253420 to
d8e6469
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #7329
Problem
When a permit is acquired, released, and then expires from the sorted set,
availablePermitsAsync()adds the expired permit count twice:release()already restored the permit and clampedcurrentValuetoraterelease()did not prune) is counted as expired and added again — without any clampThis causes
availablePermits()to return a value greater than the configured rate, and that over-limit value is persisted back to Redis.Root cause
availablePermitsAsync()line 592 addsreleasedtocurrentValuewith no rate ceiling:releaseAsync()(line 303) already has the clamp:Fix
Apply the same clamp in
availablePermitsAsync()after adding expired permits but before persistingcurrentValue.Testing
The existing
testRelease()didn't catch this because it runs fast enough that no permits reach the expiration point (released = 0). Two new tests sleep past the interval to trigger the double-counting path and assert the clamp holds.Note: I don't have Docker installed locally, so I couldn't run the
RedisDockerTest-based tests. The fix has been verified by: