938ed9a1ed
maxDownloadAttempts maps to the daemon configuration flag
--max-download-attempts int
Set the max download attempts for each pull (default 5)
and the daemon configuration machinery interprets a value of 0 as "apply
the default value" and not a valid user value (config validation/
normalization bugs notwithstanding). The intention is clearly that this
configuration value should be an upper limit on the number of times the
daemon should try to download a particular layer before giving up. So it
is surprising to have the configuration value interpreted as a _retry_
limit. The daemon will make up to N+1 attempts to download a layer! This
also means users cannot disable retries even if they wanted to.
As this is a longstanding bug, not a recent regression, it would not be
appropriate to backport the fix (
|
||
|---|---|---|
| .. | ||
| download.go | ||
| download_test.go | ||
| transfer.go | ||
| transfer_test.go | ||
| upload.go | ||
| upload_test.go | ||