Failed to download package 'System.Memory.4.5.3' from 'https://www.myget.org/F/workflow/api/v2/package/System.Memory/4.5.3'. The download of 'https://www.myget.org/F/workflow/api/v2/package/System.Memory/4.5.3' timed out because no data was received for 6

Failed to download package ‘System.Memory.4.5.3’ from ‘https://www.myget.org/F/workflow/api/v2/package/System.Memory/4.5.3’.
The download of ‘https://www.myget.org/F/workflow/api/v2/package/System.Memory/4.5.3’ timed out because no data was received for 60000ms.
Exception of type ‘System.TimeoutException’ was thrown.

Does it work now? My first guess is that there were some problems with myget at that moment

Try To Install By connecting to open network

Link need to whitelist in organization

Have you solved this problem?
I have the same situation?

Can you, please, send what was the solution?

For anyone that stumbles on this later …

TL;DR: Try to run your process again … a couple of times if needed. In our case, the issue appeared to be due to it being the initial run of a new process (on a new machine). So it just took too long for all the packages to download.

More details:
We had the same issue as the original poster (except it was a different file/package). It happened when we were running a new process.

In our case, after we got the error, we tried to access the URL to the package that timed out from another machine. We just copied the URL into a chrome browser. That other machine was able to access the file (i.e. Chrome displayed the ‘Save As’ dialog for the .nupkg file). Note: The “URL to the package” in the original poster’s case would’ve been https://www.myget.org/F/workflow/api/v2/package/System.Memory/4.5.3

We then tried to access that same URL from the machine that had the error while logged in with the bot account. Again we were able to access the URL (though we did not download it).

Then we observed that the bot had successfully downloaded several new packages to the C:\Users<bot login name>.nuget\packages\ directory during the failed run.

So we just ran the process again by starting the process from Orchestrator and assigning it to the same machine. Again it took awhile (5 minutes?) before the process actually ran (i.e. log entries appeared), but the second time it did run to completion.