I'm working with MassTransit and RabbitMQ and one of the consumer will make a batch request to the Graph API. Given that a batch may contain throttled responses, I was wondering how to properly set up the retry logic.
The guidance on GraphAPI batching states that the API's client should check the responses for each of the requests in the batch and get the RETRY_AFTER header value for each throttled response, get the MAX of those values (MAX_RETRY_AFTER), and use that as the delay before retrying.
The batch request is made from within the consumer's Consume method. So, the immediate thought is to just introduce a delay there. Next, it could either handle the retry manually or error back to the broker and let the retry policy kick in.
In the former, it feels like the consumer would become a weird kind of long running consumer. Plus, I would have to manually account for MAX_RETRIES so that it doesn't run forever.
Now, if relying on the retry policy, depending on how it's set up, it could be adding an additional delay on top of MAX_RETRY_AFTER (might be insignificant or not). And the consumer would still be "long running".
I also thought about a third option which I'm not sure is possible. That would be setting up a "dynamic" retry policy, where the delay used before retrying would be determined as part of the Consume logic.
That said, could anyone provide some guidance on these options? What would be the best practice? Any pitfalls to watch for?
Thanks in advance!