Recently I wrote about common issues with the SharePoint connector in Flow. One of the common issues I found is the error 429. No I am not talking about the Ford Mustang 429.
Error 429
Table of Contents
The general description of 429 is
Runtime error 429 is an error that causes the program, which we are using currently, to shut down suddenly. It is mainly caused due to memory issue/computer threats / conflict between software’s or registry problems.
Rate limit exceeded
When you find the 429 error messages in Microsoft Flow you will find that the issue is the
Rate limit exceeded. Try again in X seconds
The API call has therefore suddenly hung up as flow is making too many calls.
This is when you see flows failing every now and then and you can’t easily recover form these errors. As suddenly some flows are running successfully. First of all it is important to know what this rate limit is. On the SharePoint connector page you can find more details.
Now that we know that you can make 600 API calls per connection per minute. There are a few options. Use more than one connection is one option but if you are exceeding this limit then you either do have a very busy system or you should review your flows and make sure that you don’t have any spinning flows.
Quite likely you have a flow that triggers other flows. This could be because you are creating items in the same list as your triggering items or you are updating the triggering item with for example a status update.
Then quite quickly you will find that your flow run history shows a lot of running flows
And quite soon after you will find some actions retrying within your flow run history.
Once you have got to the following “Try again in 61 seconds.” you know that you are in trouble as the system should try to recover every 60 seconds.
In short you’ve got a major problem!
How to fix error 429?
What should we do to fix this. Error handling in this case is no real help as all we can do is make things worse by calling more SharePoint API calls.
I found the above error messages when my flows updated the triggering item within my flows. It is not always practical to avoid updating the triggering item. However you can minimise the number of updates and therefore protect your flow from failing.
There is an easy way around this problem. Imagine you have a flow that triggers on updates and you are updating a field within the triggering item. This flow could look like the flow below.
Now every update will trigger another flow and before you know you might have some troubles as described above.
If we now add a condition that checks the values of the fields before we do the update and only do the update if the values are different from the new values then the following expression could protect our flow:
@and(not(equals(triggerBody()?['Title'], 'test')),not(equals(triggerBody()?['requieredcolumn'], 'test')))
We now have a flow that does the necessary update to my triggering item without the danger of my flows looping forever.
It would be nice if the Update item action could check if an update is needed before doing an update by comparing values but unfortunately it doesn’t do that.
User voice
I’ve created a uservoice for this idea. Please up vote, so that we can avoid all the unnecessary conditions in flows.
Hi Pieter,
Just a quick question: How do you define a “CONNECTION”
for example: If a flow is trigger manually.
If one user trigger on their phone -> that would count as 1 connection?
A connection is created during your flow design time.So where you supply the username/password etc
Just to make sure that I understand this correctly: I have a flow in powerapps that send photos to my sharepoint library.
Around 100 users are use this for the field audit.
So the limit apply to each of this user, they cannot upload over 600 photo within 1 minute right? (since Sharepoint limit 600 APi call per Min)
Hi Minh,
It means that if you have a heavily load like that, that you need to consider building in recovery times. This can be in the triggers but also in the actions. Each trigger and each action within a connector will could as on of the 600 API calls.
I have a question. How do you get the error page?
Hi Jan,
You can get to that using the Analytics option in the flow run screen