Rate Limit not limitting
I have a simple worker that reads an API Key from D1 and shall use the rate limitter to apply limits to it.
I've configured a very small limit in my config to test it:
and I wanted to test the limit, it was not applied. Even calling it with a hard coded key does not limit it in my tests:
Am I missing something? It seems like the limitter is not incrementing.
Thanks a lot, in advance, for any help!
3 Replies
When is eventually? Should it not apply after a few seconds?
With the above example, I set it to 1 request per minute.
Running with a delay of a few seconds (5 or 30) is what I expected to be incremented at least.
reduced to the smallest testable version:
(wrangler 3.63.2)
calling:
will always return
success
– even if the second call after 10 second is above the rate limit of 1 request per minute. 10 seconds to sync the storage is something I expect.
Am I doing something wrong or is there an issue with the limitter?
if "eventually consistent" is outside of the configurable period and I can not limit someone to 1req within a 60s timeframe, whats the purpose of it at all?
I very much would love to use the new service instead of relying on my own implementation. Is there someone who can help?Did you find a solution @favo ?
I agree with what Leo says here. To expand on that, the rate limiting in Workers is not likely going to work very well for really small numbers of requests.
To ensure that your Workers are fast (and bills small 🙂 ) the counters are updated in the background. There are many servers in a Colo and there can be several POPs in an MCP to spread your requests over. If you are unlucky you may even find your requests are split between POPs. All of this is to say that the rate limit system will not know about the most recent state on all servers.
The key thing is not the 10 seconds but the vast number of servers and the odds of your 2nd curl request being routed to the same server is pretty unlikely.
If you need to rate limit on really small numbers of requests in short time periods then I recommend using another Workers product.
When using your browser, it will likely keep the connection open which will increase very significantly the chance that a 2nd and subsequent request reaches the same worker with up to date state.