Resilience to the failure of external services

[StHofmann]

As the PowerShell Gallery failed some days ago, UniGetUI complained about an corrupt installation as it could not download the winget.exe component; see the attached log of the failed updates. It suggested to repair the installation, which did not help at all as this could not resolve the root issue, which was the failed Azure cloud hosting the PowerShell Gallery.

I would thus suggest to make the program more resilient to the failure of external services on which it depends. This includes delaying operations failed due to connectivity issues (along with some meaningful user message) instead of suggesting endless repair loops that have to chance to succeed.

I know that it could be hard to decide whether connectivity issues result from internal / installation problems (for which a repair might help) or from external sources like Internet service providers / cloud services (for which a repair attempt is useless). Just as a starting point, I could think of is pinging a highly available "reference host" and executing an internal PowerShell command to distinguish between the both. For instance, pinging the localhost (to check basic IP services are working) and executing $PSVersionTable.PSVersion (to check PowerShell is responding) should allow deciding whether there's a connectivity or installation issue for which a repair might help or whether we may suspect ISP/cloud issues. More sophisticated checks could be added as reasonable or needed.

[marticliment]

UniGetUI complained about an corrupt installation as it could not download the winget.exe component

This will only happen if the winget source fails, which, as far as I know, happened too. UniGetUI detects the failure of WinGet when it does not report any installed packages, which sometimes can be the case when their sources fail.

Nevertheless, I have already pushed a commit that will make UniGetUI more resilient in case of server timeouts or source failures, to prevent issues such as the one mentioned here (see 8a788eb and 6a44948).