Open 0xc1f opened 3 years ago
Ping!
Just found this library and it has helping me doing some basic ratelimiting, so thank you for that :) I am feeling some other features are needed though here, context cancelation being one of them (if there is another lib or fork I should look at, please let me know!). If you are so inclined I can open other issues for features I think it would be nice to have
Regardless, for context cancelation I am currently resorting to this (used within an httpClient impl)
func (c *httpClient) applyRateLimit(ctx context.Context) error {
// the following goroutine + select allow us to abort waiting on
// rate limiting if the request context is done
limitingDone := make(chan struct{})
go func() {
c.limiter.Take()
close(limitingDone)
}()
select {
case <-limitingDone:
return nil
case <-ctx.Done():
return ctx.Err()
}
}
The API extension sounds reasonable, but this is not very high in my priority list - it'll likely take weeks if not months. PRs are welcome though :)
Happy to get more feature requests/issues - we can at least track them. But like above, I don't expect to be able to address them soon.
I can take on this issue. However, I'm not sure how Take()
should behave.
I know that the signature could be TakeCtx(ctx context.Context) (time.Time, error)
. I'm unsure if I can just exit the function with an error or if I have to rollback the rate limit state since it technically errored out.
Also, why do we have 3 different implementations of Limiter? Do I update all of them? It appears that only one is used.
I would recommend using https://pkg.go.dev/golang.org/x/time/rate#Limiter.Wait if it fits your requirements instead.
Given recent issues with testing & complexity of the questions you listed above, we're likely to stay with the current minimal API.
I would recommend using https://pkg.go.dev/golang.org/x/time/rate#Limiter.Wait if it fits your requirements instead.
This is what I ended up using. I just forgot it existed.
It's still weird to me to use a blocking API without context support. That's just me, though.
For my future self - #11 tried to do the same. Some code has changed, but the comments there are valuable.
I don't see why we wouldn't extend the API to allow cancellation.