Answered

PAD ERROR: There's an issue starting your desktop flow. Script:_, Run:_ is not waiting to start Check for errors and try running it again.

(0) Share

Report

Posted on by HEATFreight

1,024

We have a cloud flow that launches a desktop flow. We ran it again immediately after this error with no changes and it worked perfectly. Have never seen this error before. Can anyone shed some light on this? Why would we get this error on one run but not on the next run? Nothing changed!

There's an issue starting your desktop flow. Script: '...', Run: '...' is not waiting to start Check for errors and try running it again.

Script and Run ID numbers have been replaced with ellipses, but otherwise this is the error verbatim.

Categories:

Power Automate Desktop

I have the same question (0)

All responses (3)

Answers (1)

Rohith_Raju Microsoft Employee on at

Like (0)

Report

Hello @HEATFreight
This seems to be an intermittent issue while connecting your Desktop Flows to Cloud, which might have been resolved by itself, once you re-ran the flow and the network re-established connection.
There is not much information that I can share regarding this error, as we have not faced this error.

Was this reply helpful? Yes No
HEATFreight 1,024 on at

Like (1)

Report

Yeah, that was a weird one. I think I've only seen it once. There are very intermittent connectivity issues with PAD triggered from cloud. Usually they resolve themselves on next run.

For what it's worth, I think I was using a "machine" direct connection instead of the PAD gateway when this error occurred. However, it does seem like this new "machine" connection type is more resilient overall than the PAD gateway. And much easier to set up!

Now, let me ask a question regarding the PAD timeout setting, which may shed some light on what could be happening. Well actually, if this was a timeout error, I would expect to see the error mention the PAD flow timing out which it did not, but anyway I have timeout set to about PT0H4M. My question is: if there are multiple flows queued up to run on the same PAD "machine" or gateway, and not a cluster of machines or gateways, when does the timeout begin counting? Does the timeout setting —which is set in the settings menu of the "Run a desktop flow" action in the Power Automate Cloud flow— does that timeout start when the cloud flow first initiates the PAD action, or maybe once the previous flow in the queue has finished, or does it start once the PAD flow has actually begun running on the machine?!?!? Also, does it start when PAD begins downloading the flow in the background, or does the timer start once the flow is downloaded and has actually begun running?

Because of how long PAD flows can take to finish downloading there's a HUGE difference in functionality depending on when that timeout actually begins! And regardless, re-downloading every flow upon start of flow run is maddeningly inefficient! This is a massively frustrating aspect of PAD! Why on god's green Earth do we need to re-download the dang flow every time? Seems like that is one of the biggest sources of error regarding flow timeouts —if indeed the timeout begins before the PAD flow has even downloaded itself. WHY NOT CACHE?!?!?!? My local PAD instance should keep track of changes to my PAD flows and periodically cache them locally so that there's not this ridiculous lag between flow launch and flow execution. Frickin' ridiculous. How did you guys ship this? Who signed off on this crap? It's seriously awful. Microsoft Power Automate is amazing. It has been a wonderous addition to our business and it saves us from spending an inordinate amount of time on menial tasks. It's truly a technological wonder. You can be your own dev! No expert programming skills required. If you're good at spreadsheets and spreadsheet logic, then Power Automate is as easy as PowerPoint. But it don't cache!!!!!! WTF Microsoft. I fully realize that you guys are probably have security issues and malware issues and whatnot, and this must be why you don't cache locally, but that needs to change. Figure. It. Out.

Annnnywho, when does the timeout timer start? Anyone know? Options I can think of are:
•Timer starts as soon as Cloud Flow PAD action starts
•Timer starts as soon as previous PAD flow has finished
•Timer starts as soon as PAD flow download begins
•Timer starts as soon as PAD flow download has finished and the actual flow begins running

Was this reply helpful? Yes No
Verified answer

HEATFreight 1,024 on at

Like (1)

Report

By the way, giving 16GB of RAM to the virtual machines which run our PAD flows has resolved this issue! It's been 7 months since I posted this, and we have been using PAD flows flawlessly since then. We upgraded our hardware in a few ways.

Even if you think you have enough RAM for Windows 10 + PAD, you may be surprised how much resources a PAD flow will use when it's trying to launch itself. It has to load into RAM all of the applications or programs which the flow will use. In my experience, a VM with 8 GB of RAM is not sufficient, even if the VM shows low memory usage of less than 4GB, PAD still needs a lot more than the remaining 4+ GB of RAM available. With 16GB allotted to each VM, there is always at least about 12GB available at any time for PAD to use, and that has made all the difference.

My host machine (Dell Optiplex 7070 small form factor) now has 64GB of RAM, an upgraded 500W Dell PSU, and a GTX 1050 graphics card. With this configuration, I can run 2 virtual machines all the time to process incoming PAD flows in the background of my host machine (attended flows but not really attended...). Works great!

Was this reply helpful? Yes No