samarabbas
commented
3 years ago @mfateev any thoughts on this issue?
Another potential solution is to use rate limit TaskQueues. The only problem is currently we rate limit based on rps, as oppose to total outstanding requests which is needed by this use case.
yiminc
Is your feature request related to a problem? Please describe.
In our system, we use Redis as a counting semaphore. We want to restrict a certain code path to only have 10 requests in flight for example. This situation is somewhat related to:
Our current solution is to retry in a timeframe based on the timeout period of this semaphore with configurable jitter.
Describe the solution you'd like Add a "RetryIn" field to the retryable errors. Just like whether a retryable or nonretryable error can be returned, this can be used to set when this would be retried. A corresponding change on the SDK side would have to be made as well.
Describe alternatives you've considered N/A
Additional context I think this feature is a nice-to-have, but not a must have. We could always configure our retry policy to be of a certain timeframe without the jitter, and it'd mostly be fine. I'm not that worried about stampeding herd in our system, but I would imagine that jitter would be helpful here too (maybe support for that would be good enough?).