Standard resilience pipeline: shouldn't "Total request timeout" policy come before "Rate limiter" policy?

[tyler-boyd]

re: #5078 (comment)

I would love to see an explanation for why the policies are there in the order they are in.

As an example, why is the total request timeout policy inside/after the rate limit policy, when the rate limit policy can cause large delays if you enable queueing? For example...if you have a queue size of 10 and parallelism 1 and total request timeout = 30s, in the worst case scenario it could take that 10th queued request up to 300s, which is 10x higher than the total request timeout.

This is either bad or I'm misunderstanding something, and it would be much easier to tell which if the motivation behind the standard policies were shared.

I would have expected the total request timeout to be able to cancel a queued rate limit policy, but either deliberately or accidentally, this doesn't appear to be the case. Alternatively, perhaps a way to configure a "max queueing time" on the rate limit policy would help?

Thanks in advance!