vutran1710 / PyrateLimiter

⚔️Python Rate-Limiter using Leaky-Bucket Algorithm Family
https://pyratelimiter.readthedocs.io
MIT License
334 stars 36 forks source link

Remaining Time Removal #152

Open rexdjw opened 6 months ago

rexdjw commented 6 months ago

I'm upgrading a new project to the current release version and I noticed that the remaining time key was removed from the exception meta info. What is the new process that we're expected to use? That key was very useful for rescheduling calls

vutran1710 commented 6 months ago

In case of rescheduling, can you just use delay?

rexdjw commented 6 months ago

Well, I see 2 issues with delay. Please correct me where my assumptions are wrong.

First, without the remaining time, I don't have a way to set a delay in such a manner that it guarantees that the request fires, or efficiently fires. It's either waiting an unnecessary amount of time or not waiting long enough (and canceling).

Second, my rate limiting integration is coupled with celery (which doesn't support async). Therefore, having a worker sit in a time.sleep waiting on a delay call isn't very ideal. It was quite convenient to schedule a new celery task on the time remaining field. While I understand that you can't support all design decisions, the removal of the time remaining makes the calls volatile in such a manner that rescheduling them efficiently doesn't appear possible. Even for users running the limiter async in an event loop, the delay is either excessive, or the request must be rescheduled an indeterminable number of times while running a conservative delay.

vutran1710 commented 6 months ago

I see your point! I'll address the problem soon.