Retry failed downloads before giving up

[heydojo]

Builds randomly fail for me if there is network traffic congestion or some other connection issue.

For example, I see:

Starting package 20/31: jasper:x64-windows
Building package jasper[core]:x64-windows...
-- Downloading https://github.com/mdadams/jasper/archive/version-2.0.16.tar.gz...
-- Downloading https://github.com/mdadams/jasper/archive/version-2.0.16.tar.gz... Failed. Status: 22;"HTTP response code said error"
CMake Error at scripts/cmake/vcpkg_download_distfile.cmake:175 (message):

      Failed to download file.
      If you use a proxy, please set the HTTPS_PROXY and HTTP_PROXY environment
      variables to "https://user:password@your-proxy-ip-address:port/".
      Otherwise, please submit an issue at https://github.com/Microsoft/vcpkg/issues

Call Stack (most recent call first):
  scripts/cmake/vcpkg_from_github.cmake:132 (vcpkg_download_distfile)
  ports/jasper/portfile.cmake:3 (vcpkg_from_github)
  scripts/ports.cmake:90 (include)


Error: Building package jasper:x64-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with `.\vcpkg update`, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
  Package: jasper:x64-windows
  Vcpkg version: 2020.02.04-nohash-external

Additionally, attach any relevant sections from the log files above.

But I then re-run the vcpkg install command and the installation transaction succeeds without the same error.

Proposed solution

I think the download client (aria2 iirc) needs to try three times with approximately a three second pause in between each retry before giving up and allowing the build to fail.

Other package managers elsewhere do this and retry at least once in the event of a download error.
Some also provide cached mirror copies of source archives as a fall back in the event of a download error, which may also be an area of enhancement for another time.

Additional context
The reason the current method is bad is that if you currently use vcpkg with CI/CD then a single vcpkg download failure may provide a build failure for your build or test environment.

Three download retry attempts for source archives would be optimal to try to minimise such failures.

[heydojo]

https://github.com/microsoft/vcpkg/blob/master/scripts/cmake/vcpkg_download_distfile.cmake#L127

Please consider adding some or all of the following:

• -m 3 https://aria2.github.io/manual/en/html/aria2c.html#cmdoption-m
• --retry-wait=3 https://aria2.github.io/manual/en/html/aria2c.html#cmdoption-retry-wait
• --max-file-not-found=3 https://aria2.github.io/manual/en/html/aria2c.html#cmdoption-max-file-not-found

Thanks!

[JackBoosY]

I think this issue was resolved.

[albertvaka]

I don't think it was... or if there's an option to retry, I can't seem to find it. What is the option?

[JackBoosY]

@albertvaka After double confirm, it isn't.

[webbtrail]

I am still running into this problem. I am preparing to write a wrapper script around the vcpkg invocation to end this tiring issue.
I was originally told that if I brought the VCPkg installation out of the Visual Studio tree, then the lock on the file would work as designed. I have done that. The problem is the same as always (I can get updates more quickly). It is a difficult situation, and I would prefer any hints or workarounds available.

[dg0yt]

Glad to see asset caching being used.
Could you add more detail? The original issue and output is from 2020, and the vcpkg tool is very different in 2025. There is no other mention of "lock on the file" here, so it is not clear if it is the same issue.

[webbtrail]

The lock on the file is associated with whether you are using manifest install or not. I have tried turning off manifest install, and a whole new set of issues appeared.

I am currently running VCPkg/2025-09-17. I will likely update later today to 2025-10-17. If I have time, I will try turning off MANIFEST_INSTALL again.

I ran into an issue a few months back, where if you enabled VCPKG_TRACE_FIND_PACKAGE, then I would get a "repeat count is not a positive number". I use a large number of packages, all source, primarily from github.

# .../vcpkg/scripts/buildsystems/vcpkg.cmake(777):  if(VCPKG_TRACE_FIND_PACKAGE )
# .../vcpkg/scripts/buildsystems/vcpkg.cmake(778):
#                               string(REPEAT    ${z_vcpkg_find_package_backup_id} z_vcpkg_find_package_indent )
# CMake Error at ../vcpkg/scripts/buildsystems/vcpkg.cmake:778 (string):
#   repeat count is not a positive number.
#set(VCPKG_TRACE_FIND_PACKAGE    ON  CACHE BOOL      "${_OV_ITF_DOC_TAG}"    FORCE)

I cannot submit direct bug reports from within Visual Studio. Their bug reporting subsystem is flagged as a "man in the middle" hacking attack and blocked.

[dg0yt]

VCPKG_TRACE_FIND_PACKAGE is for tracing find_package in CMake project mode.
vcpkg_from_... downloads are executed in CMake script mode.
There is no connection between the two. No further discussion of VCPKG_TRACE_FIND_PACKAGE belongs here in #20583.

[dg0yt]

I use a large number of packages, all source, primarily from github.

Speculation:
a) There is a bad package, which invokes vcpkg on its own in an uncoordinated way.
b) You hit a downlaod rate limit.

[webbtrail]

Yes, I know they are not connected. It's just an example of odd issues I have run across

[webbtrail]

Inadvertently, i had given multiple build threads read/write access to the asset cache. They were fighting over update rights. Fixing this, so far no problems.