JacksonK.52224 (Customer) asked a question.
I have two independent workflows that go off when a user is deactivated:
- Transfers google drive from deactivated user to whomever requested
- Transfers google calendar from deactivated user to whomever requested
I noticed that I received a "Error 409 conflict" for one of these workflows:
I then thought since "data transfer already in progress" means that one transfer that went off is causing issues for the other transfer that wants to run at the same time. I created a buffer for google calendar to run after 5 minutes and had no more issues.
My question is if the issue is in-fact due to 2 transfers trying to run at the same time. So I'm wondering if it'll be an issue in the future if the drive transfer started but was not fully complete in 5 minutes and will cause another conflict with google calendar, or would it not matter at all and the transfer requests just need a small buffer between in order to initiate and the time after for drive files to fully transfer does not matter?
And if we would need to actually wait for the drive transfer to fully complete, I'm wondering if the better option is to start the google calendar transfer request first and give drive transfer a 5 minute delay just incase the off boarded user has many files that would take time to fully transfer over?
Hello @JacksonK.52224 (Customer)
One thing to keep in mind is that Workflows is a tool making API calls to endpoints. The endpoints are the ones performing the actions. The 409 is a response error from the endpoint you are connecting with. In this described use case it appears Google hasn't completed doing something before you made another request to take an action against the same resource hence the "Data transfer already in progress" error message.
From the Workflows side what you can do is place the action in an If/Error which is a Try/Catch block. So, try to do this thing. If this thing errors AND the error is 409 continue with this new action. The new action could be for example: Wait 5 minutes then try the same API call.
If you want to get real creative you could have the action in its own helper flow. Wait "counter" in minutes with counter starting at 0. And "IF" (counter is less than 3) AND If error occurs increase the counter and then re-call the helper flow to try again. This way you could try the call again at now(counter0), wait 1 minuteS(counter1), wait 2 minutes (counter2), fail(index3) to else block and do some other action.