Skip to content

[BUG] Sliding-window rate limiter ignores requestCount and over-reports remaining requests #8442

Open

Description

@Aias00

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

RedisRateLimiter passes requestCount as the fourth script argument for every algorithm:

https://github.com/apache/shenyu/blob/9dd9a12fb/shenyu-plugin/shenyu-plugin-fault-tolerance/shenyu-plugin-ratelimiter/src/main/java/org/apache/shenyu/plugin/ratelimiter/executor/RedisRateLimiter.java#L56-L60

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]:

https://github.com/apache/shenyu/blob/9dd9a12fb/shenyu-plugin/shenyu-plugin-fault-tolerance/shenyu-plugin-ratelimiter/src/main/resources/META-INF/scripts/sliding_window_request_rate_limiter.lua#L42-L54

local remain_request = capacity - last_requested
local allowed_num = 0
if (last_requested < capacity) then
    allowed_num = 1
    redis.call('zadd', tokens_key, now, timestamp_key)
end
...
return { allowed_num, remain_request }
  1. 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.
  2. 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

  1. Enable the rateLimiter plugin with Redis.
  2. Create a rule with algorithmName=slidingWindow, replenishRate=10, burstCapacity=10, requestCount=5.
  3. 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.

Activity

  1. konlue commented on Nov 12, 2026

    @konlue
    Contributor

    /assign

  2. konlue commented on Nov 12, 2026

    @konlue
    Contributor

    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.

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

Metadata

Metadata

Assignees

Labels

type: bugSomething isn't working

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions