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

Aperta Adatta ai principianti
#8,442 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
83/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
java, lua, redis
Ambito
backend, databases

Direzione di ricerca

Leggi RedisRateLimiter.java e sliding_window_request_rate_limiter.lua, quindi confronta come gli script del token bucket e del leaky bucket usano ARGV[4]. Aggiorna il comportamento della finestra scorrevole in modo da tenere conto di requestCount quando si verifica la capacità, si registra l’utilizzo e si riportano le richieste rimanenti. Il lavoro è completato quando il comportamento corrisponde ai risultati attesi nell’issue; aggiungi o esegui i test pertinenti del limitatore di richieste.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Java
Stelle
8.9k
Fork
3.1k
Merge medio
2g 1h
PR unite (30g)
362

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di apache/shenyu

Tutte le issue di apache/shenyu

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.