Closed tobiasdcl closed 12 months ago
@gurgunday @kibertoad
I can submit a PR but would like some guidance about the approach. Given that the issue is in an underlying library (if my understanding is correct) I am not sure if you want to revert to the prev. LRU cache or wait for a fix in toad-cache
Here are also some more details. The problem is that the lru.first
is set to null
if a value is first set
and then retrieved via get
and once lru.first
is set to null
it is just a matter of time before reaching the cache limit causing the first evict
call - from that point on it is game over 😅
probably has to be fixed in toad-cache and not here.
probably has to be fixed in toad-cache and not here.
I created a PR 🙌
Nice job!
Thank you so much for the PR!
@tobiasdcl 9.0.1 with the fix was released! thank you for the report and the PR
@tobiasdcl 9.0.1 with the fix was released! thank you for the report and the PR
Awesome, thank you for the super fast fix 🥳
Prerequisites
Fastify version
4.24.3
Plugin version
9.0.0
Node.js version
20.9.0
Operating system
Linux
Operating system version (i.e. 20.04, 11.3, 10)
Ubuntu 22.04
Description
Hey folks, first of all thanks for building and maintaining this library ❤️
I found a bug in the most recent version of
fastify-rate-limit
(9.0.0
at the time of writing) when using the defaultLocalStore
.Summary
Based on my current understanding the root cause is a bug in the underlying LRU implementation toad-cache - I will create a dedicated issue there and link it here (update: done).
Impact
If triggered, all routes protected by
fastify-rate-limit
will be persitently error outSteps to Reproduce
create the following file as
repro.mjs
and then runnode repro.mjs
raw output from
node repro.mjs
:prettified stacktrace:
Expected Behavior
Expected Behavior:
Actual Behavior: