From 2074688be947274084eae87e59ea7d5108130889 Mon Sep 17 00:00:00 2001 From: Aaron Lehmann Date: Tue, 21 Feb 2023 20:57:50 -0800 Subject: [PATCH] Fix S3 multipart upload pagination loop condition The loop that iterates over paginated lists of S3 multipart upload parts appears to be using the wrong variable in its loop condition. Nothing inside the loop affects the value of `resp.IsTruncated`, so this loop will either be wrongly skipped or loop forever. It looks like this is a regression caused by commit 7736319f2ed49768b9d9eb832465a1317dd0b106. The return value of `ListMultipartUploads` used to be assigned to a variable named `resp`, but it was renamed to `partsList` without updating the for loop condition. I believe this is causing an error we're seeing with large layer uploads at commit time: upload resumed at wrong offset: 5242880000 != 5815706782 Missing parts of the multipart S3 upload would cause an incorrect size calculation in `newWriter`. Signed-off-by: Aaron Lehmann --- registry/storage/driver/s3-aws/s3.go | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/registry/storage/driver/s3-aws/s3.go b/registry/storage/driver/s3-aws/s3.go index 01985230..28af4dab 100644 --- a/registry/storage/driver/s3-aws/s3.go +++ b/registry/storage/driver/s3-aws/s3.go @@ -690,7 +690,7 @@ func (d *driver) Writer(ctx context.Context, path string, appendParam bool) (sto return nil, parseError(path, err) } allParts = append(allParts, partsList.Parts...) - for *resp.IsTruncated { + for *partsList.IsTruncated { partsList, err = d.S3.ListParts(&s3.ListPartsInput{ Bucket: aws.String(d.Bucket), Key: aws.String(key),