Skip to content

fix: fix azure multipart upload objects masking#2012

Open
niksis02 wants to merge 1 commit intomainfrom
sis/azure-mp-blobs
Open

fix: fix azure multipart upload objects masking#2012
niksis02 wants to merge 1 commit intomainfrom
sis/azure-mp-blobs

Conversation

@niksis02
Copy link
Copy Markdown
Contributor

@niksis02 niksis02 commented Apr 3, 2026

As multipart uploads are translated to blobs in azure blob storage, they were visible in ListObjects(V2) as complete objects. Now the blobs with multipart prefix are filtered out during listing.

The listing logic is rewritten client-side to implement proper S3 semantics: flat blob enumeration with manual delimiter handling, correct truncation (IsTruncated only set when more items genuinely exist beyond maxKeys), and StartAfter/Marker/ContinuationToken applied via the lexicographic max of both constraints in ListObjectsV2.

For the same reason bucket deletion was not allowed. Now multipart objects are explicitly checked on bucket deletion and any pending multipart upload doesn't block the bucket deletion anymore.

@niksis02 niksis02 self-assigned this Apr 3, 2026
@niksis02 niksis02 requested a review from benmcclelland April 3, 2026 11:42
@benmcclelland
Copy link
Copy Markdown
Member

In the loop fetching pages, the no-StartAfter path exits after the first page. If a page contains only hidden multipart entries, the response can still be empty while real objects exist on later pages. We might need to continue paging until collected visible results (or exhaust pages), and count only visible entries against MaxKeys.

The tmp multipart namespace can still leak via CommonPrefixes. With delimiter-based listing, users can still see .sgwtmp prefixes I think.

Is there a way to add a prefix filter to mask sgwtmp in the backend request?

As multipart uploads are translated to blobs in azure blob storage, they were visible in ListObjects(V2) as complete objects. Now the blobs with multipart prefix are filtered out during listing.

The listing logic is rewritten client-side to implement proper S3 semantics: flat blob enumeration with manual delimiter handling, correct truncation (IsTruncated only set when more items genuinely exist beyond maxKeys), and StartAfter/Marker/ContinuationToken applied via the lexicographic max of both constraints in ListObjectsV2.

For the same reason bucket deletion was not allowed. Now multipart objects are explicitly checked on bucket deletion and any pending multipart upload doesn't block the bucket deletion anymore.
@niksis02 niksis02 force-pushed the sis/azure-mp-blobs branch from 726fc86 to 13dbbf5 Compare April 6, 2026 21:31
@niksis02 niksis02 requested review from benmcclelland and removed request for benmcclelland April 6, 2026 21:47
} else {
if pastMax {
isTruncated = true
break
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this needs to break the outer loop here?

// If we already reached maxKeys, this new unique CP means truncation
if pastMax {
isTruncated = true
break
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also break outer loop here?

if len(pg.Segment.BlobItems) > 0 {
return s3err.GetAPIError(s3err.ErrBucketNotEmpty)
for _, item := range pg.Segment.BlobItems {
// the bucket is not empty, if any no multipart upload object is present
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

slightly confusing wording here, maybe something like:
// ignore temp multipart objects when determining if bucket non-empty

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants