## Summary The sequential download of a presigned cache URL makes one GET without `Range` ([`downloadPresignedSequential`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/b130a28af451b8b1044ad68b7c77e33d1669eb63/commands/helpers/cache_extractor.go#L310-L329)) and accepts any `2xx` answer: `getCache` returns the response with `retryOnServerError`, which returns no error for every `2xx` ([`cache_extractor.go#L194-L205`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/b130a28af451b8b1044ad68b7c77e33d1669eb63/commands/helpers/cache_extractor.go#L194-L205), [`retry_helper.go#L88-L91`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/b130a28af451b8b1044ad68b7c77e33d1669eb63/commands/helpers/retry_helper.go#L88-L91)). A `206 Partial Content` holds only part of the object, but the extractor writes it as the archive and sets the object's `Last-Modified` on it, so the next run finds the archive up to date and keeps it. A server answers a GET without `Range` with a `206` when it is a caching proxy whose cache key leaves out `Range` and which has stored a `206`. One Range request through it is enough to store one, for example the `bytes=0-0` probe of a runner with `FF_USE_PARALLEL_CACHE_TRANSFER` enabled. With the caching proxy configuration used in the review of !7635 ([note](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/7635#note_4010945732)), nginx 1.31.6 answers a GET without `Range` after a `bytes=0-0` request with the stored `206 Partial Content`, `Content-Range: bytes 0-0/100000` and one byte (`X-Cache: HIT`). The proxy is misconfigured, but the runner cannot tell its answer from a complete download. This is also why !7635 makes the parallel cache download fall back to the sequential GET only when a chunk is answered with `200`, and not when it is answered with a `206` for another range: behind such a proxy the sequential GET gets the same partial `206`. ## Steps to reproduce On `main` (b130a28a), add this test to `commands/helpers/cache_extractor_test.go` (it uses that file's imports and helpers, plus `sync/atomic`) and run `go test -run TestPresignedSequentialKeepsPartialResponse -v ./commands/helpers/`. The `httptest` server answers every request the way that proxy does once it has stored the probe's answer. `FF_USE_PARALLEL_CACHE_TRANSFER` is not set, so the extractor makes only the sequential GET. ```go func TestPresignedSequentialKeepsPartialResponse(t *testing.T) { cdTempDir(t) payload := parallelTestZipBytes(t) lm := time.Date(2020, 5, 1, 12, 0, 0, 0, time.UTC).Format(http.TimeFormat) var requests atomic.Int64 ts := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { requests.Add(1) w.Header().Set("Last-Modified", lm) w.Header().Set("Content-Range", fmt.Sprintf("bytes 0-0/%d", len(payload))) w.WriteHeader(http.StatusPartialContent) _, _ = w.Write(payload[:1]) })) t.Cleanup(ts.Close) cmd := CacheExtractorCommand{ File: cacheExtractorArchive, URL: ts.URL + "/cache.zip", TransferBufferSize: defaultCacheTransferBufferSize, } err := cmd.handlePresignedURL() got, _ := os.ReadFile(cacheExtractorArchive) t.Logf("first run: err=%v archive=%d bytes of %d", err, len(got), len(payload)) err = cmd.handlePresignedURL() got, _ = os.ReadFile(cacheExtractorArchive) t.Logf("second run: err=%v archive=%d bytes, %d requests in all", err, len(got), requests.Load()) } ``` It prints: ```plaintext first run: err=<nil> archive=1 bytes of 159 level=info msg="archive.zip is up to date" second run: err=<nil> archive=1 bytes, 2 requests in all ``` ## Actual behavior The download reports success and leaves one byte of the object as the archive. Every later run takes that archive as up to date, so the job keeps running with a broken cache until the object changes. ## Expected behavior A GET without `Range` is answered with `200` and the whole object. Any other answer, a `206` included, fails the download instead of being written as the archive. ## Relevant logs and/or screenshots The test output above. ## Environment description Any executor using a presigned cache URL, with a caching proxy in front of the object store whose cache key leaves out `Range` and which stores `206` responses. The proxy only needs to have seen one Range request for the object, from this runner or from another one. ### Used GitLab Runner version GitLab Runner v19.5.0, whose `cache_extractor.go` and `retry_helper.go` are the same as at the commit below. `main` at b130a28af451b8b1044ad68b7c77e33d1669eb63. `retryOnServerError` has accepted any `2xx` since v11.10.0. ## Possible fixes In `downloadPresignedSequential`, or in `getCache` for this caller, accept only `200` and fail on a `206` (the request carries no `Range`, so a `206` cannot be the whole object), without writing anything.