Skip to content

Fix throttler documented as computing a divided rate instead of an absolute count - #985

Open
coipond-writer[bot] wants to merge 1 commit into
masterfrom
fix/rate-limiting-absolute-count-not-divided-rate-44186
Open

Fix throttler documented as computing a divided rate instead of an absolute count#985
coipond-writer[bot] wants to merge 1 commit into
masterfrom
fix/rate-limiting-absolute-count-not-divided-rate-44186

Conversation

@coipond-writer

Copy link
Copy Markdown
Contributor

What

`Pro/Consumer-Groups/Rate-Limiting.md:3` said the throttler "calculates the consumption rate by dividing the number of messages consumed in the window by the window size" and compares that rate against the limit.

Why it's wrong

`pro/processing/consumer_groups/filters/throttler.rb:59-81` (`#apply!`) purges entries older than the window, sums the remaining counts, and compares that sum against an absolute `@limit` -- no division anywhere, matching the code's own comment ("at most 100 messages in a 60 second rolling window").

Fixed to describe the actual mechanism: an absolute message-count cap within a rolling window, not a computed rate.

Fixes #44186 (Redmine, confidence: likely -- independently re-confirmed against source before fixing).

…solute count

pro/processing/consumer_groups/filters/throttler.rb:59-81 (#apply!)
purges entries older than the window, sums the remaining counts, and
compares that sum against an absolute @limit - no division anywhere,
matching the code's own comment ("at most 100 messages in a 60 second
rolling window").

The page described the throttler as dividing messages-in-window by
window size to get a "consumption rate" and comparing that rate to the
limit. Fixed to describe the actual mechanism: an absolute message-count
cap within a rolling window.

Fixes #44186.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

0 participants