jamalveli 1a92f39b46 fix: prevent nil pointer panic in s3proxy ListMultipartUploads and ListParts ...

Both methods unconditionally dereferenced several optional *string/*int32/
*bool response fields from the upstream S3 SDK response (KeyMarker,
UploadIdMarker, NextKeyMarker, NextUploadIdMarker, Delimiter, Prefix,
MaxUploads/MaxParts, IsTruncated, PartNumberMarker/NextPartNumberMarker,
Initiator, Owner). The AWS SDK leaves these nil whenever the corresponding
XML element is absent from the response - which happens whenever the
result isn't truncated (the terminal page of any pagination loop) or an
optional request parameter wasn't set. This is a guaranteed panic on every
completed ListParts pagination and on the common ListMultipartUploads case
of a non-truncated result.

Replace the unconditional dereferences with nil-safe aws.To* accessors,
and default the PartNumberMarker/NextPartNumberMarker string-to-int parse
to 0 when the field is absent, matching the semantics of "no marker".

Verified locally against a real S3 backend: both calls previously panicked
(500 InternalError) on every invocation; after this change,
ListMultipartUploads, CreateMultipartUpload, UploadPart, ListParts, and
AbortMultipartUpload all complete successfully with no panics.

2026-07-14 01:11:39 +03:00

..

client.go

fix: add gcs compatibility flag to fix s3proxy GCS SigV4 signature mismatch

2026-04-14 10:53:26 -07:00

s3.go

fix: prevent nil pointer panic in s3proxy ListMultipartUploads and ListParts

2026-07-14 01:11:39 +03:00