aaditya-srivathsan

It is async. `await.limiter.try_acquire(name, weight)` is how we use it. You could imagine us trying to rate limit n different endpoint with n different rate limits and thats one reason...

Also a followup here, even if we implement a multi bucket controlled by a dictionary, wouldnt then the case threadpool also have to be dynamic in this case? or do...

Followup 2: If we were to limit usage of an endpoint(i.e a bucket) for every callerID and have multiple different rates based on a callerID(rates will vary based on payment...

Sounds good let me test it out. Just confirming, do I still need to call a schedule_leak for every new bucket being created and also still create the threadpool to...

The change looks like it is working, although i do see a runtime warning here ``` usr/local/lib/python3.10/site-packages/pyrate_limiter/abstracts/bucket.py:133: RuntimeWarning: coroutine 'Redis.execute_command' was never awaited if isawaitable(bucket.leak(0)): RuntimeWarning: Enable tracemalloc to get...

sounds good! thanks for the quick assistance!

@ganeshku1 any update on this?

Sure let me try this and ill let you know if this works or not

This did help thank you very much!