You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
request_rate_limiter.lua (token bucket) and request_leaky_rate_limiter.lua read it as local requested = tonumber(ARGV[4]). sliding_window_request_rate_limiter.lua never reads ARGV[4]:
A rule with algorithmName=slidingWindow and requestCount=N consumes 1 unit per request instead of N, so it admits N times more requests than the same handle under tokenBucket or leakyBucket.
remain_request is computed before the current request is added, so the reported remaining count is one higher than the real value after an allowed request.
Expected Behavior
The sliding window admits a request only if last_requested + requestCount <= capacity, records requestCount units, and returns capacity - last_requested - requestCount as the remaining count, consistent with the other algorithms.
Steps To Reproduce
Enable the rateLimiter plugin with Redis.
Create a rule with algorithmName=slidingWindow, replenishRate=10, burstCapacity=10, requestCount=5.
Send 10 requests within one second. All 10 are allowed, while tokenBucket with the same handle allows 2.
Environment
ShenYu version(s): master @ 9dd9a12fb
Debug logs
No response
Anything else?
Found by static code review; I have not yet run the reproduction against Redis.
Implementation plan: make sliding_window_request_rate_limiter.lua read requestCount (ARGV[4]) and record that many units in the existing sorted set (members KEYS[2] .. ':' .. i, still bounded by capacity), admit only when last_requested + requestCount <= capacity, and return capacity - last_requested - requestCount after recording, clamped at 0 on rejection. Non-positive values count as one request; fractional values round up so a fractional count never admits more traffic than configured. No Java change is needed — RedisRateLimiter already forwards the argument and the plugin only consumes the allowed flag. Regression tests execute the real script against embedded Redis with fixed timestamps, including the issue's requestCount=5 scenario.
Activity
konlue commentedon Nov 12, 2026
/assign
konlue commentedon Nov 12, 2026
Implementation plan: make
sliding_window_request_rate_limiter.luareadrequestCount(ARGV[4]) and record that many units in the existing sorted set (membersKEYS[2] .. ':' .. i, still bounded bycapacity), admit only whenlast_requested + requestCount <= capacity, and returncapacity - last_requested - requestCountafter recording, clamped at 0 on rejection. Non-positive values count as one request; fractional values round up so a fractional count never admits more traffic than configured. No Java change is needed —RedisRateLimiteralready forwards the argument and the plugin only consumes the allowed flag. Regression tests execute the real script against embedded Redis with fixed timestamps, including the issue'srequestCount=5scenario.