fix: stop hitting additional rate limit windows once a client is already limited#686
Open
Priyanshubhartistm wants to merge 1 commit into
Open
Conversation
…ady limited isRateLimited() in EventMessageHandler and WebSocketAdapter iterated every configured rate limit window and called rateLimiter.hit() even after an earlier window had already tripped. Each hit() call executes a Lua script against Redis, so a client already being rate-limited caused N redundant Redis writes per message instead of one. Both methods now return as soon as the first exceeded window is found. Signed-off-by: Priyanshubhartistm <bhartipriyanshustm@gmail.com>
🦋 Changeset detectedLatest commit: 55d770c The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Collaborator
|
Coverage is 67.648% — Priyanshubhartistm:fix/rate-limiter-continues-after-hit into cameri:main. No base build found for |
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
2 participants
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.
Description
isRateLimited()inEventMessageHandler(eventetAdapter(message rate limiting) looped through every configured rate limit window and calledrateLimiter.hit()for each one, even after an eop had already reported the client as rate-limited. Both methods nowreturn` as soon as thefirst exceeded window is found, instead of continRedis for)
every remaining window.
Related Issue
Fixes #685
Motivation and Context
Both
hit()implementations (SlidingWindowRateLexecute a Lua script against Redis on every call (a ZADD/HSET write). Once a client is already known to be rate-limited, continuing to hit everypure waste: a burst of messages/events from an already-limited client multiplies Redis writes by the number of configured windows, for no behavioral beturnstrue`/rejects the message either way).How Has This Been Tested?
test/unit/handlers/event-erting that once the first configured rate limit window reports limited, no furtherhit()` calls are made for subsequent windows.test/unit/adapters/web-socket-adapter.spec.tsdriving the same scenario through the public `onClientMh.pnpm run test:unit) — all 1395 tests pass, confirming no existing test relied on thevior.pnpm lint,pnpm check:deps,pnpm run build,pnpm run build:check,pnpm run verify:cli:build, `pnpm run test:cli — all pass.pnpm run docker:test:integration(99 scenarios): 97 passed, including theRate Limiterfeaturepnpm check:formatreports pre-existing formatut the error count is identical with and without this change, and none of the flagged lines are inthe diff — confirmed against the unmodified bas
Screenshots (if appropriate):
N/A — backend logic change only.
Types of changes
Checklist: