I’m currently working on a workflow that uses the “Wait for Download” activity in UiPath. Once the file is downloaded, I need to rename it. To ensure that UiPath has enough time to detect the downloaded file, I added a 5-second delay before the renaming step.
However, I still encounter an issue intermittently where UiPath throws the following error:
“Source file does not exist”
This seems to suggest that even after the delay, UiPath is sometimes still unable to detect the file.
Added a delay of 5 seconds before renaming the file – this works sometimes, but not consistently.
Updated the UiPath.System and UiPath.UIAutomation packages – this seemed to resolve the issue temporarily for a day, but then the problem reappeared.
What I’m Considering:
To make this more robust, I’m thinking about two possible solutions:
Retry Scope: Keep checking for the file and proceed once it’s detected. While Loop: Keep retrying until the file is identified by UiPath before renaming.
My Questions:
Is there any best practice or built-in feature in UiPath to handle this kind of situation more reliably?
Are there alternative solutions or patterns (like monitoring the folder directly or checking for file lock status) that you would recommend?
A combination of Retry Scope + file lock check is the most reliable UiPath approach. Adding a File System Watcher can further improve responsiveness but may add complexity.
Not recommended but Might be helpful:
If helpful, mark as solution Tick.
Happy automation with UiPath
After adding the activity of wait for download activity, make sure that activity is downloading your file.
if its downloaded add a while activity and in condition section pass True and
In body section use file exists activity which gives you Boolean value whether file is downloaded or not,
if it true you can use rename file activity to rename the file after that you can use break activity to come out the loop.
or else keep it blank or any log message for your references.
You don’t need to do this. The entire point to the Wait for Download activity is that the next activity isn’t processed until the download completes. The most likely solution is you need to use the “Ignore these temporary file extensions” property because whatever is being downloaded is first being saved as a tmp (or some other extension) before the download completes.
Thank you for your suggestions. I plan to try each of them in order of complexity and will confirm which one works best. Interestingly, the issue only occurs during the very first execution of the day—the robot fails on the first run but works fine from the second attempt onward. Since I can only test this once per day, it may take some time to verify. I appreciate your patience.
