# Feature Request: More robust retry policy for FetchContent / ExternalProject\_Add in download.cmake

**URL:** https://discourse.cmake.org/t/feature-request-more-robust-retry-policy-for-fetchcontent-externalproject-add-in-download-cmake/7560
**Category:** Development
**Created:** [February 27, 2023, 7:54pm UTC](https://discourse.cmake.org/t/feature-request-more-robust-retry-policy-for-fetchcontent-externalproject-add-in-download-cmake/7560 "2023-02-27T19:54:44Z")
**Posts on this page:** 8
**Page:** 1

<div class="post-metadata">

### Author: ![Greg](https://discourse.cmake.org/user_avatar/discourse.cmake.org/greg/32/565_2.png) [@Greg](https://discourse.cmake.org/u/Greg)
#### Post date: [February 27, 2023, 7:54pm UTC](https://discourse.cmake.org/t/feature-request-more-robust-retry-policy-for-fetchcontent-externalproject-add-in-download-cmake/7560/1 "2023-02-27T19:54:44Z")

</div>

I have a CI builds which occasionally fail in FetchContent when downloading an URL with the error

status\_code: 28  
status\_string: “Timeout was reached”

which is unfortunate. I guess this machine is on a intermittently flaky network. I see that this FetchContent is a wrapper around ExternalProject\_Add, which is calling FILE DOWNLOAD, which generates the errror.

My feature requests:

- Is there any documentation for what the error codes from FILE DOWNLOAD are? The documentation I see just says “0 is no error”
- I see that download.cmake has a list of retry-able errors from FILE DOWNLOAD:

`set(download_retry_codes 7 6 8 15)`

```
 Can we add "28" (timeout) to this list of retry-able error codes?
 Are there any other error codes which should be retry-able?

```

Is best practice to wrap FetchContent in a loop in this case, where we see rare, but ongoing network failures?

Thanks,

-greg

---

<div class="post-metadata">

### Author: ![craig.scott](https://discourse.cmake.org/user_avatar/discourse.cmake.org/craig.scott/32/20_2.png) [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [February 28, 2023, 8:34pm UTC](https://discourse.cmake.org/t/feature-request-more-robust-retry-policy-for-fetchcontent-externalproject-add-in-download-cmake/7560/2 "2023-02-28T20:34:27Z")

</div>

@ben.boeckel @brad.king Do either of you know the history behind why those particular error codes were added?

> [@Greg](#):
>
> Is best practice to wrap FetchContent in a loop in this case, where we see rare, but ongoing network failures?

No, I wouldn’t normally recommend that. We should be able to handle brief network outages within CMake’s implementation. See [issue 24410](https://gitlab.kitware.com/cmake/cmake/-/issues/24410#note_1326169) for a somewhat related discussion. If your infrastructure is fairly unreliable and network problems are common or take non-trivial time to resolve, looping to retry is probably just going to take longer and still fail.

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [February 28, 2023, 10:12pm UTC](https://discourse.cmake.org/t/feature-request-more-robust-retry-policy-for-fetchcontent-externalproject-add-in-download-cmake/7560/3 "2023-02-28T22:12:13Z")

</div>

The error codes probably correspond with `curl` exit codes.

```auto
       6 Could not resolve host. The given remote host could not be resolved.
       7 Failed to connect to host.
       8 Weird server reply. The server sent data curl could not parse.
…
       15 FTP cannot use host. Could not resolve the host IP we got in the 227-line.

```

which mostly look like host lookup-related issues. As for why 8 and not 13 or 14 which deals with strange FTP responses…no idea.

---

<div class="post-metadata">

### Author: ![scivision](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/s/a87d85/32.png) [@scivision](https://discourse.cmake.org/u/scivision)
#### Post date: [March 1, 2023, 1:20am UTC](https://discourse.cmake.org/t/feature-request-more-robust-retry-policy-for-fetchcontent-externalproject-add-in-download-cmake/7560/4 "2023-03-01T01:20:17Z")

</div>

This is an example of using `file(DOWNLOAD)` to feed into FetchContent, to allow more download option control. [CMake FetchContent with manual download and optional retry · GitHub](https://gist.github.com/scivision/8bce2a0e3e5fdc217473aaa53600eeb6)

---

<div class="post-metadata">

### Author: ![Greg](https://discourse.cmake.org/user_avatar/discourse.cmake.org/greg/32/565_2.png) [@Greg](https://discourse.cmake.org/u/Greg)
#### Post date: [March 1, 2023, 1:53am UTC](https://discourse.cmake.org/t/feature-request-more-robust-retry-policy-for-fetchcontent-externalproject-add-in-download-cmake/7560/5 "2023-03-01T01:53:38Z")

</div>

Thanks, Craig, especially for the related issue. I’m also curious where the “right” place in the stack for a retry should be – there’s one in curl file download code. Seems wrong to have a separate retry loop, perhaps with separate backoff times in the git clone code.

I’ve added the smallest possible MR to add 28 (timeout) to the list of retryable curl errors. Do with that what you will.

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [March 1, 2023, 8:06pm UTC](https://discourse.cmake.org/t/feature-request-more-robust-retry-policy-for-fetchcontent-externalproject-add-in-download-cmake/7560/6 "2023-03-01T20:06:33Z")

</div>

> [@Greg](#):
>
> I’ve added the smallest possible MR add 28 (timeout) to the list of retryable curl errors

For reference, that is [CMake MR 8270](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8270).

---

<div class="post-metadata">

### Author: ![nvartolomei](https://discourse.cmake.org/user_avatar/discourse.cmake.org/nvartolomei/32/5123_2.png) [@nvartolomei](https://discourse.cmake.org/u/nvartolomei)
#### Post date: [November 12, 2024, 4:18pm UTC](https://discourse.cmake.org/t/feature-request-more-robust-retry-policy-for-fetchcontent-externalproject-add-in-download-cmake/7560/7 "2024-11-12T16:18:44Z")

</div>

Hi. Can we add retries for 500/503 response codes as well? When files are downloaded from s3 I intermittently get these errors which are mitigated by a retry.

Unfortunately curl does not have a special return code for these and all http status codes \>= 400 fall under error code 22 so it isn’t as straightforward to implement.

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [July 20, 2025, 1:46am UTC](https://discourse.cmake.org/t/feature-request-more-robust-retry-policy-for-fetchcontent-externalproject-add-in-download-cmake/7560/8 "2025-07-20T01:46:09Z")

</div>

503 in particular seems ill-advised for automated retries given that it means the server is overloaded. Maybe we could use a list of additional status codes to perform retries for so that it can be used for specific things (like AWS where you probably just need to wait for elasticity to respond).

Note that `file(DOWNLOAD)` _should_ have the HTTP status code available…probably worth making sure that’s the case.