fix: report remaining, not elapsed, time from LinearRateLimiter - #3521
Draft
csviri wants to merge 1 commit into
Draft
fix: report remaining, not elapsed, time from LinearRateLimiter#3521csviri wants to merge 1 commit into
csviri wants to merge 1 commit into
Conversation
`RateLimiter.isLimited` is documented to return the "minimal duration
until a permission could be acquired again", but `LinearRateLimiter`
returned the time *elapsed* since the current period started:
Duration.between(actualState.getLastRefreshTime(), LocalDateTime.now())
The two are inverted. Measured with a 1000ms refresh period:
moment reported correct
right after limit hit 19ms ~1000ms
800ms into the period 804ms ~200ms
`EventProcessor.handleRateLimitedSubmission` feeds this value straight
into `TimerEventSource.scheduleOnce`, so a rate-limited resource is
rescheduled almost immediately after the limit is reached (floored at
MINIMAL_RATE_LIMIT_RESCHEDULE_DURATION), gets rate-limited again, and
repeats — producing a burst of pointless timer events. Conversely, a
resource limited near the end of a period waits roughly a full extra
period after a permission was already available.
Now returns the time until the current period ends, clamped at zero.
`returnsMinimalDurationToAcquirePermission` only asserted
`isLessThan(REFRESH_PERIOD)`, which held for both the correct and the
inverted value; it now also asserts the reported wait is close to the
full period. A second test asserts the reported duration shrinks as the
period elapses, which is what distinguishes remaining from elapsed. Both
fail without this change.
16 tasks
Contributor
There was a problem hiding this comment.
Pull request overview
Fixes LinearRateLimiter#isLimited to report the remaining time until a permission can be acquired (as documented), preventing overly-early rescheduling of rate-limited resources.
Changes:
- Update
LinearRateLimiter.isLimitedto compute remaining time in the current refresh period (clamped at zero). - Strengthen
returnsMinimalDurationToAcquirePermissionto assert the reported wait is close to the full refresh period. - Add a regression test ensuring the reported duration decreases as the refresh period elapses.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/event/rate/LinearRateLimiter.java | Switches isLimited from reporting elapsed time to reporting remaining time in the refresh period. |
| operator-framework-core/src/test/java/io/javaoperatorsdk/operator/processing/event/rate/LinearRateLimiterTest.java | Updates and adds tests to distinguish “remaining” vs “elapsed” duration behavior. |
Comment on lines
+66
to
+71
| var justAfterLimit = rl.isLimited(state).orElseThrow(); | ||
| Thread.sleep(REFRESH_PERIOD.toMillis() / 2); | ||
| var halfWayThroughPeriod = rl.isLimited(state).orElseThrow(); | ||
|
|
||
| // as the refresh period elapses, less time remains until a permission is available again | ||
| assertThat(halfWayThroughPeriod).isLessThan(justAfterLimit); |
Comment on lines
+67
to
+70
| var remaining = | ||
| Duration.between( | ||
| LocalDateTime.now(), actualState.getLastRefreshTime().plus(refreshPeriod)); | ||
| return Optional.of(remaining.isNegative() ? Duration.ZERO : remaining); |
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.
RateLimiter.isLimitedis documented to return the "minimal durationuntil a permission could be acquired again", but
LinearRateLimiterreturned the time elapsed since the current period started:
The two are inverted. Measured with a 1000ms refresh period:
EventProcessor.handleRateLimitedSubmissionfeeds this value straightinto
TimerEventSource.scheduleOnce, so a rate-limited resource isrescheduled almost immediately after the limit is reached (floored at
MINIMAL_RATE_LIMIT_RESCHEDULE_DURATION), gets rate-limited again, and
repeats — producing a burst of pointless timer events. Conversely, a
resource limited near the end of a period waits roughly a full extra
period after a permission was already available.
Now returns the time until the current period ends, clamped at zero.
returnsMinimalDurationToAcquirePermissiononly assertedisLessThan(REFRESH_PERIOD), which held for both the correct and theinverted value; it now also asserts the reported wait is close to the
full period. A second test asserts the reported duration shrinks as the
period elapses, which is what distinguishes remaining from elapsed. Both
fail without this change.
Part of #3517