[BUG] Sliding-window rate limiter ignores requestCount and over-reports remaining requests
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
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
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:
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]:
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 }
- A rule with
algorithmName=slidingWindowandrequestCount=Nconsumes 1 unit per request instead of N, so it admits N times more requests than the same handle undertokenBucketorleakyBucket. remain_requestis 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
tokenBucketwith 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
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
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di apache/shenyu
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 83/100
I maintainer di solito rispondono entro 1 giorno
-
[BUG] Boolean tars parameter parsed via Byte.valueOf → NumberFormatExceptionForse già presa @yangjj-iso l’ha presa 26 giorni fa. Apertaplugin: tars priority: medium type: bug
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 82/100
apache/shenyu#6736 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
[BUG] ShenyuMcpResponseDecorator reads buffer before super.writeWith, corrupting forwarded bodyForse di nuovo libera Una pull request per questa issue è stata chiusa senza essere unita. Apertafeature: plugin priority: high type: bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
apache/shenyu#6641 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
admin: permission priority: medium type: bug
Difficoltà 1/5 1-3 ore Idoneità per principianti 78/100
apache/shenyu#6549 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
[BUG] Node sync auth and metadata deletes unsubscribe the wrong cache keyForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
apache/shenyu#6478 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di apache/shenyu
Issue simili
-
ImporterNoConsensus and ImporterFileVerificationErrors alerts can't fire on consensus failureApertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
hiero-ledger/hiero-mirror-node#14665 ·
I maintainer di solito rispondono entro 1 giorno
-
kind/bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
cadence-workflow/cadence#8745 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
oracle/graalvm-reachability-metadata#12168 ·
I maintainer di solito rispondono entro 1 giorno
-
area/frontend area/test kind/tech-debt
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
camunda/camunda#69073 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Patient profile returns a server error for a person with observation periods but no clinical recordsForse già presa @DG47 l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
I maintainer di solito rispondono entro 1 giorno