• This issue is blocking
• This issue is causing unreasonable pain

As requested in #7910 will try to show my pain here to facilitate discussion.

Consider scenario where external contributor of dotnet runtime, for example, have bad internet connection where downloading NET takes more then 20 minutes. You run, wait 20 min, fail. Try again because it’s not very obvious what happens, maybe it’s network glitch. That can repeat couple times until you give up. Either you abandon idea of contribution this time, or start troubleshooting. I would speculate that most people do now know how Arcade do it’s magic. Finding location where dotnet downloads was not very obvious for me first time. So in hope that having explicit download timeout in the Arcade code can helps with finding such value, because Timeout is nice searchable term.

Reason why I do not want increase value following — 20 minutes is already a lot of time, and if some network issues arise it’s really depends on the environment. And larger value can make troubleshooting bad networking in CI a pain.

Indirect pain for me was that I did not know where to configure timeouts. I also independently hit issue with Wix downloading on older version, so I incorrectly understand problem and add dotnet/msbuild#7541, only to realize that it's fixed by @MichalStrehovsky in #8385. Experience troubleshooting Wix download was fine since I clearly saw proj file which has issue, and it was a matter of applying timeout. My incorrect assumption about DownloadTask source was my mistake. If I hit error in

then probably I would figure out that I should manually set Timeout because it is task from Arcade