Configure Retry Policy to resolve Rate limit exceeded-429 error code in Power Automate
Recently I have encountered an issue where power automate was failing due to an error with HTTP status code 429 -Rate limit is exceeded.
Scenario: I have configured an action Get User of Graph API Azure AD connector to get ‘object id’ of a user based on user principal in a flow, this power automate was running on the update of contact record of Microsoft Dynamics CRM, so when I did a bulk update, then Get User API failed for large number of records.
Cause: Flow was making too many calls to the Graph API because of bulk update.
Error Description: HTTP status code 429 with error message as Rate-Limit is exceeded try again, it also had Retry-After response header in addition to the 429 response code and information related to ‘number of seconds’ it needs to wait before making more requests.
Solution: After analysing the issue, I decided to change the Retry Policy of the action to reduce the load on the Azure AD connector.
Before implementing the solution, let’s understand what Retry policy means.
When the request times out or fails with error code 429, 408 and 5xx response, then action retries that request after a random or fixed interval of time before sending the next request to an API.
If you don’t specify a retry policy in an action, then it uses the default policy, which is actually the Exponential Interval type.
You can change the type of Retry Policy, from the Settings of an action in a flow. You can either set it exponential or fixed interval as shown below:
Let’s understand how Exponential Interval policy works:
If request fails or times out, then in case of exponential interval, it increases the waiting time between retries after each retry failure and this can be achieved by specifying maximum and minimum interval waiting time.
For example: When request fails the first time, it retries after 2 seconds. If it fails again then it waits for 4 seconds before next retry. If it again fails then it waits for another 8 seconds before sending the next request and so on. After each failure it incrementally increases the wait time between the successive retry requests and it keeps retrying and keeps increasing the delay time till the maximum retry count is hit. Therefore it helps the service to reduce the load by giving some rest period for processing all the requests.
If the request is failing even after maximum retries, then you will get time out or service unavailable error from the service you are calling.
Fixed Interval
If requests fails with 429 error, then action retries after waiting for a specified fixed amount of time before sending the next request to the API.
For example:
- Retry Policy Type: Fixed Interval
- Retry Count: 5
- Interval: PT40S (It means 40 seconds retry interval in the ISO-8601 Data elements)
In this case, if API request fails then this action tries to call the API four more times with a 40 seconds delay in each call.
Another approach to resolve this issue:
If request fails with 429 error code, Microsoft Graph continues to log resource usage while a client is being throttled, to resolve this you can stop the request from being retried for specified interval of time based on Retry-After response header information to recover from throttling. While implementing error handling in your flow or code, you can retry the request after waiting for the specified number of seconds in the Retry-After response header.
If the request fails again with a 429 status code, then continue to use the recommended Retry-After delay and retry the request.
If you are using Common Data Service then I would recommend to go through below link to understand how Retry-After duration and Service protection API limits are enforced.
