Repository navigation
Limiter does not work #35
Description
My code is as following:
constructor:()=>{
this.RateLimiterOnSeconds = new RateLimiter(4, 1*1000); // 5 requests per second
this.RateLimiterOnHours = new RateLimiter(2000, 1*1000*60*60); // 2000 request per hour
}
sendReq1: ()=>{
schedule(..)
}
sendReq2: ()=>{
schedule(...)
}
schedule: (fn)=>{
this.RateLimiterOnSeconds.removeTokens(1,(err, remainingRequests)=>{
this.RateLimiterOnHours.removeTokens(1, () => {
console.log('request executed in second...',new Date().getTime()/1000, remainingRequests);
fn();
});
});
}
The limit is exceeded.
Indeed, the console.log in the schedule() method prints:
request executed in second... 1487770295.951 4
request executed in second... 1487770296.043 4
request executed in second... 1487770296.219 4
request executed in second... 1487770296.258 4
request executed in second... 1487770296.427 4
request executed in second... 1487770296.56 4
request executed in second... 1487770296.628 4
request executed in second... 1487770296.803 4
request executed in second... 1487770296.831 4
request executed in second... 1487770296.921 4
request executed in second... 1487770297.126 4
request executed in second... 1487770297.214 4
request executed in second... 1487770297.311 4
request executed in second... 1487770297.421 4
request executed in second... 1487770297.605 4
request executed in second... 1487770297.686 4
request executed in second... 1487770297.803 4
and as you can see, in the second 1487770297 there are 7 requests (instead of 5), and number of tokens to remove is constant.
Activity
hcientist commentedon Mar 20, 2017
@bitliner (i know this is not your primary concern, but I also want to use this package and am trying to troubleshoot) why does your code say
wouldn't this be 4 per second?
also, your comment points to second
1487770297, but doesn't second1487770296already demonstrate too many requests per second?also, I cannot replicate your issue with static
remainingRequests.here is my test:
for which i get the output:
hcientist commentedon Mar 21, 2017
I am trying to limit a call to an external API to 5 queries per second and 200 queries per minute. My code is like below:
here is some output of a test with 1000 queries (I have the test stop when it detects the service has cut us off due to exceeding rate limits):
hcientist commentedon Apr 20, 2017
perhaps this would be a better approach for my project? https://github.com/eventEmitter/request-rate-limiter will update
jonathanstokes commentedon Mar 15, 2019
I have this same problem. It's like the whole purpose of the library isn't working.
josh-mercarto commentedon Apr 18, 2020
This library is still not working for me. This simple test fails and my
mockFnis never called.jhurliman commentedon Apr 18, 2020
@josh-mercarto that test looks like you are expecting the callback to have been synchronously executed before moving to the next line? That won’t happen.
Issue jhurliman#35 limiter is not working
boly38 commentedon Apr 4, 2021
Hello,
following #68 I'm using this lib on my website which is making rate limited etsy api call (creharmony/node-etsy-client#19)
I encounter issue because when setting rate limiter do 10 or 9,8,or 7 per seconds, I reached etsy limits in any cases (10/sec).
So for me there is an issue I'm trying to understand. To diagnose this library, I've done a little sample.
==> cf draft PR #70
What I encounter during my tests:
I dont see a fix for this 2017 issue so I'm less and less confident in this library. Any hint would be greatly appreciated
jhurliman commentedon Sep 10, 2026
The concurrent allowance and initial-interval bugs are fixed in 4.0.0 and covered by deterministic regressions. There is also a separate composition issue in the original example: awaiting two independent limiters does not reserve both budgets at the eventual work start, so work can accumulate behind the second limiter. #105 documents this distinction and the fixed-window limitation explicitly. Parent/child TokenBuckets provide atomic hierarchical token-bucket accounting, but do not provide strict sliding-window limits. Leaving this open through review of the clarification rather than claiming that arbitrary sequential limiter composition is fixed.
Add cooldown estimates and prepare limiter 4.1 (#105)