## Summary With `FF_USE_PARALLEL_ARTIFACT_TRANSFER` enabled and `direct_download` redirected to object storage, `DownloadArtifacts` first writes the chunks it gets with `WriteAt` at their offsets, up to the size the probe reported. When a chunk fails, it falls back to a single GET and copies the body into the same file from offset 0 ([`gitlab.go#L1362-L1372`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/b130a28af451b8b1044ad68b7c77e33d1669eb63/network/gitlab.go#L1362-L1372), [`#L1448`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/b130a28af451b8b1044ad68b7c77e33d1669eb63/network/gitlab.go#L1448)), but nothing truncates the file. If the body of that GET is shorter than the size the parallel attempt saw, for example because the object was replaced in between, the end of the file keeps the bytes of the parallel attempt and the download still reports `DownloadSucceeded`. The caller creates the file once per attempt ([`artifacts_downloader.go#L61`](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/b130a28af451b8b1044ad68b7c77e33d1669eb63/commands/helpers/artifacts_downloader.go#L61)), so the parallel attempt and the fallback share it. It was found in the review of !7635 ([note](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/7635#note_4010945732)), where a run with `httptest` left a file of 33555456 bytes where 16777226 were expected. The case needs the object to change between the probe and the fallback, so it is unlikely, but the result is a corrupt artifact reported as a success. ## Steps to reproduce On `main` (b130a28a), add this test to `network/gitlab_test.go` (it uses that file's imports, plus `helpers/featureflags`) and run `go test -run TestDownloadArtifactsFallbackKeepsStaleTail -v ./network/`. The middle chunk of three fails with `503`, and the single GET of the fallback answers with a shorter object. ```go func TestDownloadArtifactsFallbackKeepsStaleTail(t *testing.T) { t.Setenv(featureflags.UseParallelArtifactTransfer, "true") const size = 2*artifactParallelChunkSize + 1024 short := []byte("the object as the single-stream GET sees it") server := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { switch { case r.URL.Path == "/api/v4/jobs/10/artifacts": http.Redirect(w, r, "http://"+r.Host+"/artifacts.zip", http.StatusFound) case r.Header.Get("Range") == "": _, _ = w.Write(short) default: var start, end int _, _ = fmt.Sscanf(r.Header.Get("Range"), "bytes=%d-%d", &start, &end) if start == artifactParallelChunkSize { http.Error(w, "unavailable", http.StatusServiceUnavailable) return } w.Header().Set("Content-Range", fmt.Sprintf("bytes %d-%d/%d", start, end, size)) w.WriteHeader(http.StatusPartialContent) _, _ = w.Write(make([]byte, end-start+1)) } })) defer server.Close() path := filepath.Join(t.TempDir(), "artifacts.zip") dest, err := os.Create(path) require.NoError(t, err) defer dest.Close() directDownload := true state := NewGitLabClient().DownloadArtifacts(JobCredentials{ID: 10, URL: server.URL, Token: "token"}, dest, &directDownload) info, err := os.Stat(path) require.NoError(t, err) t.Logf("succeeded=%v file=%d bytes, single-stream body=%d bytes", state == DownloadSucceeded, info.Size(), len(short)) } ``` It prints: ```plaintext succeeded=true file=33555456 bytes, single-stream body=43 bytes ``` ## Actual behavior The fallback overwrites the start of the file and leaves the rest of what the parallel attempt wrote. The artifact is corrupt and the download reports success. ## Expected behavior The fallback starts from an empty file, so the artifact is exactly the body of the single GET. ## Relevant logs and/or screenshots The test output above. ## Environment description Any executor, with `FF_USE_PARALLEL_ARTIFACT_TRANSFER` enabled (the flag defaults to `false`), `direct_download` redirected to object storage, a chunk that fails, and an object that changes before the fallback GET. ### Used GitLab Runner version GitLab Runner v19.5.0, whose `network/gitlab.go` and `artifacts_downloader.go` are the same as at the commit below. `main` at b130a28af451b8b1044ad68b7c77e33d1669eb63, and the same code since the parallel artifact download was added in v19.0.0. ## Possible fixes Before the fallback writes anything, truncate the file and seek to its start when the destination supports it (`Truncate` and `Seek` on `*os.File`), or have the parallel attempt write to a temporary file that is renamed only on success, as the cache extractor does.