[Question]: Excluding specific executions from RateLimit count

[andrei-micuda]

What are you wanting to achieve?

I am trying to exclude specific user callback executions from counting towards a RateLimit's execution count.

What code or approach do you have so far?

I have a use case where I have to communicate with an external API that is rate limited. I am using a ResiliencePipeline with a Retry and a RateLimit strategy. What I would like to do is control which executions of the callback count towards the Polly rate limit. For example, if my piece of code gets a HttpTimeout when trying to call the external API, I would like to exclude this execution from the Permit count (since the call did not actually hit the external API, the external APIs rate limit remains unchanged). Is there any way of achieving this?

Additional context

No response

[martincostello]

Our rate limiting strategy builds on top of the .NET Rate Limiting functionality.

If you configure a rate limit using a partition that correlates to specific user (docs) and then associate that rate limiter with the strategy, you should get the behaviour you desire.

If you clone my martincostello/polly-sandbox repository, you'll find code in there that does essentially that.

[andrei-micuda]

Thank you for the quick response. I looked through the repository and the file you linked, but I still don't quite understand how using a partitioned rate limiter would help in this scenario. Could you please elaborate further? I want to reactively decide whether the execution should count towards the limit or not. From my understanding, partitioning the rate limit would require prior knowledge about which requests should count towards the limit and which shouldn't.

[martincostello]

Ah I see, I misunderstood the question.

I'm not aware of a way to do that - my understanding is that leases are managed at the point of them being acquired based on the partition (in the linked code, the User Agent or authentication header), and then while executing, a slot is used.

I'm not sure how you could apply a rate limiter that way, as you would need to do the request first before knowing whether to limit it, or you'd need to retroactively change the internal statistics in the event of an exception to have it not count to the permit lease it had just used (which wouldn't work if that request never proceeded because the permits were already exhausted).

What you're trying to do is outside the scope of Polly though - we just use the rate limiting functionality wrapped in a strategy to make composition simpler.

Generally I would not recommend double-rate-limiting client and server side. If a server has a rate limit, then always delegate to it as it is the source-of-truth. You'll never get 100% accuracy client-side. Use its responses (HTTP 429/Retry-After header) to determine whether to do things like circuit break, retry etc.