Recently I wrote about common issues with the SharePoint connector in Flow. One of the common issuesFord Mustang 429 I found is the error 429. No I am not talking about the Ford Mustang 429.

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.

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.

Flow analytics showing 429 error

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.

Silly flow with on create trigger and two create item actions

Then quite quickly you will find that your flow run history shows a lot of running flows

Run History with many running flows

And quite soon after you will find some actions retrying within your flow run history.

Create item with a retry

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.

Rate limit is exceeded. Try again in 61 seconds.

In short you’ve got a major problem!

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.

When an item is created or modified trigger followed by an update item actionNow 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:update item action within a condition

@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.

I’ve created a uservoice for this idea. Please up vote, so that we can avoid all the unnecessary conditions in flows.

 

Advertisements