## Summary With `FF_USE_PARALLEL_CACHE_TRANSFER` or `FF_USE_PARALLEL_ARTIFACT_TRANSFER` enabled, the chunk fetchers accept both `200 OK` and `206 Partial Content` for each chunk Range GET: `presignedRangeFetchChunk` for presigned cache URLs ([`commands/helpers/cache_extractor.go#L350`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/3c07c5b00216be9c2312e1d411de4c146607146d/commands/helpers/cache_extractor.go#L350)) and `fetchChunk` in `tryArtifactParallelDownload` for artifacts ([`network/gitlab.go#L1224`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/3c07c5b00216be9c2312e1d411de4c146607146d/network/gitlab.go#L1224)). A `200` means the server ignored `Range` and sent the whole object from byte 0. `transfer.ParallelRangeDownload` reads the first chunk length bytes of that body and writes them with `WriteAt` at the chunk's offset ([`helpers/transfer/parallel_download.go#L52-71`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/3c07c5b00216be9c2312e1d411de4c146607146d/helpers/transfer/parallel_download.go#L52-71)), so every chunk answered with `200` holds the opening bytes of the object instead of its own. The download reports success, so the artifact download does not fall back to its single download stream, and the cache archive or the artifact on disk is corrupted. The single-byte probe already treats `200` as "Range not honored" ([`cache_extractor.go#L273`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/3c07c5b00216be9c2312e1d411de4c146607146d/commands/helpers/cache_extractor.go#L273), [`gitlab.go#L1342`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/3c07c5b00216be9c2312e1d411de4c146607146d/network/gitlab.go#L1342)), but it only sees the first request. A CDN, a proxy or a load-balanced object store can still answer a later chunk request with `200`, for example when only some of its nodes or cache tiers support ranges. ## Steps to reproduce No object store is needed. On `main` (3c07c5b0), add this test to `commands/helpers/cache_extractor_test.go` (it uses that file's imports and test helpers) and run `go test -run TestPresignedParallelFullBodyChunk -v ./commands/helpers/`: ```go func TestPresignedParallelFullBodyChunk(t *testing.T) { cdTempDir(t) payload := parallelTestZipBytes(t) lm := time.Date(2020, 5, 1, 12, 0, 0, 0, time.UTC).Format(http.TimeFormat) rangeHandler := testParallelPresignedCacheHandler(t, payload, lm) // The probe (bytes=0-0) and the first chunk get 206; every later chunk gets 200 and the whole object. ts := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { if start, _, ok := parseBytesRangeHeader(r.Header.Get("Range")); ok && start > 0 { w.Header().Set("Last-Modified", lm) w.WriteHeader(http.StatusOK) _, _ = w.Write(payload) return } rangeHandler(w, r) })) t.Cleanup(ts.Close) cmd := CacheExtractorCommand{File: cacheExtractorArchive, URL: ts.URL + "/cache.zip", ChunkSize: 7, Concurrency: 4} done, err := cmd.tryPresignedParallelDownload() t.Logf("done=%v err=%v", done, err) got, err := os.ReadFile(cacheExtractorArchive) require.NoError(t, err) _, zerr := zip.NewReader(bytes.NewReader(got), int64(len(got))) t.Logf("equal to the object: %v, zip.NewReader: %v", bytes.Equal(got, payload), zerr) } ``` It prints: ```plaintext done=true err=<nil> equal to the object: false, zip.NewReader: zip: not a valid zip file ``` 144 of the archive's 159 bytes differ from the object. The artifact path does the same: with the same kind of server, `tryArtifactParallelDownload` returns `true` for a 16 MiB + 1 KiB object, and the last 1024 bytes of the file are the first 1024 bytes of the object. ## Actual behavior A chunk answered with `200` is written at its offset from a body that starts at byte 0. The download reports success and leaves a corrupted cache archive or artifact on disk. The corrupt cache archive keeps the object's `Last-Modified` time, so calling `tryPresignedParallelDownload` again in the test above sends only the probe, logs `archive.zip is up to date` and leaves the corrupt file in place. ## Expected behavior A chunk answered with anything other than `206` fails the parallel download, as the probe already does for the first request. The artifact download then falls back to a single download stream, as it does for any failed parallel download, and the cache extractor reports the failure instead of writing a corrupt archive. ## Relevant logs and/or screenshots The test output above. ## Environment description Any executor, with `FF_USE_PARALLEL_CACHE_TRANSFER` (cache download from a presigned URL, `Concurrency` above 1) or `FF_USE_PARALLEL_ARTIFACT_TRANSFER` (artifact download with `direct_download` redirected to object storage) enabled, against a server that answers some Range requests with `200`. Both flags default to `false`. ### Used GitLab Runner version `main` at 3c07c5b00216be9c2312e1d411de4c146607146d. The same status check is in v19.0.0, where !6401 added both fetchers, and in v19.4.1. ## Possible fixes Accept only `206` in both chunk fetchers. I have a merge request ready for it.