The execution of template action ‘Return_value(s)_to_Power_Virtual_Agents’ is failed: the client application timed out waiting for a response from service. This means that workflow took longer to respond than the allotted timeout value. The connection maintained between the client application and service will be closed and client application will get an HTTP status code 504 Gateway Timeout.
Power Automate
If you’ve gotten this error in a Power Automate flow called by Power Virtual Agents, you’ve come to the right place! This error is actually very similar to one that happens when a Power Automate process called by Power Apps takes too long to complete as well. What’s the fix?
The Solution:
The way to solve this problem is by understanding that:
- Power Virtual Agents will throw an error when your Flow hasn’t returned anything after 99 seconds,
- There currently is no way to increase this timeout
Having this information helps us turn our focus to what we can control inside the flow. The alternative to not handling this is that your user is presented with an unfriendly error message that you can’t entirely control.
Essentially, we’re looking at the following options (and/or a combination of them) and a similar approach may work if you’re experiencing the same issue with Power Apps:
- Look to optimize the calls in your flow that are taking the longest to complete
- Look at HTTP calls, custom connectors, i.e. any actions that are taking a long time to complete; look for ways to optimize these actions by reviewing code, looking for batching opportunities, etc.
- Consider offloading things in your flow that can be completed in parallel to the main thread that needs to retrieve the data for your virtual agent. This could be done by using parallel paths in your flow and/or utilizing separate flows that handle the steps that the return value is not dependent on
- Account for the possibility of a timeout within your flow by using a parallel path
- The first path is the work you’ve already completed, and would be considered the ‘happy path’ where everything happens before a timeout occurs
- The second (newer) path is one where we’re going to insert a delay action that waits 95 seconds (I know I mentioned it fails once it reaches 100 seconds but you don’t want to chance your flow taking a few seconds to get to this point and still failing to return something in time to PVA; if you’re risk-adverse, you could opt for a lower amount such as <= 90 seconds)
- After this delay add another “Return value(s) to Power Virtual Agents” action and return something to the end user letting them know the process took longer than normal to complete. Ensure the output variables in this return action match your primary return action so that there isn’t a conflict in determining what the flow is returning to the virtual agent.
- (Optional) Add additional logic to intelligently handle when a timeout has occurred
- Set a variable at the start of your flow called “HasTimedOut” and default it to false
- After your delay has passed, you know the flow is just about to time out, so set your global “HasTimedOut” variable to true
- Depending on your use case, consider taking a different action in your main thread if you get to the end and see that “HasTimedOut” is true. An example of this could be using the “Post message in a chat or channel” with the “Post as: Power Virtual Agent” action where the bot can proactively reach back out to the user with the information they were seeking
The final solution at a high level will look something like this:
One final bit of complete-up I recommend is that since you have 2 return actions in your flow, whichever one finishes second is always going to cause an error when it realizes something was already returned to the virtual agent, but if our delay return action is the one that fails, that actually means our flow was successful, because in a perfect world our flow returns what we want before we have to return a message indicating the process took too long to complete. While your user will be unaware regardless of whether you handle this or not, if you want to track the status of successful versus failed flows, I recommend doing the following:
- Directly underneath the return action on the parallel path that executes when the flow is going to timeout, add a “Terminate” action and set the status to ‘Succeeded’
- Set this new action’s “Configure run after” to only run when the action before it failed
By doing the above, you’ll essentially being ignoring an error when the timeout action failed to respond because the action you wanted to succeed is the one that won out.
As always, I hope this has been helpful and that it was able to resolve your issue.
Cheers,
Matt
