Proposal Details

Proposal Details

Currently, golang.org/x/time/rate.Limiter provides handy Wait and WaitN methods. But when using them, it is not really possible to know later on if they have waited at all (so if rate limiting was applied) or not. Just observing from outside there might be regular overhead executing the method which added delay. But knowing if rate limiting was applied or not is useful so that one can log that, compute stats, know how often rate limiting is necessary and if maybe rate limits have to be increased.

I am interested in the use case where I use Limiter to limit my own calls towards a 3rd party API endpoint. I want to collect stats for our services how often and how much rate limiting we had to do on our side. If that rate limiting is too high, we can consider buying a higher class service from a 3rd party API provider. We collect stats how long each API call took, but without knowing how long were we waiting on our side for rate limiting, it is not enough to know why some calls took longer than other. We can measure from outside how long did call to Wait and WaitN took, but that then also measures overhead of calling them.

So I propose that Wait and WaitN methods of Limiter return wait time, literally, the value of delay variable the method wait computes. wait is already internal implementation so if we want to keep backwards compatibility of Wait and WaitN methods we can introduce some new methods like WaitAndReport which would call same internal wait, just return the delay value.