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

Open Beginner friendly
  • Is something wrong?
#8,442 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
83/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
java, lua, redis
Domain
backend, databases

Research direction

Read RedisRateLimiter.java and sliding_window_request_rate_limiter.lua, then compare how the token bucket and leaky bucket scripts use ARGV[4]. Update the sliding window behavior to account for requestCount when checking capacity, recording usage, and reporting remaining requests. Done when the behavior matches the expected results in the issue; add or run the relevant rate limiter tests.

Written by the indexing model from the issue text.

Description

type: bug
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.

Dominant language
Java
Stars
8.9k
Forks
3.1k
Avg merge
2d 1h
Merged PRs (30d)
362

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/shenyu

All issues in apache/shenyu

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.