Skip to content

Conversation

@wty-Bryant
Copy link
Contributor

@wty-Bryant wty-Bryant commented Dec 14, 2025

Update remaining features to transfer manager v2 according to latest SEP specification:

  • Reshape all public APIs' input/output fields to pointer type to align with other service clients
  • Add log warning for failed multipart upload
  • Remove Range and PartNum input and related workflow from DownloadObject/GetObject
  • Remove checksum value in DownloadObject/GetObject output when the checksum type is composite
  • Add range validation for multipart downloads' single GET response
  • Add failure policy as input for directory upload and download call
  • Remove customized delimiter as input for directory upload/download

@wty-Bryant wty-Bryant requested a review from a team as a code owner December 14, 2025 18:24
if err != nil {
d.setErr(fmt.Errorf("error when heading info of object %s: %v", data.key, err))
} else {
d.incrObjectsFailed(1)
Copy link
Contributor

Choose a reason for hiding this comment

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

above you mention about object failed

this value might not be the real number of failure if user passed a customized failure policy

but couldn't we just still increment the count of objects failed, even if the user passes a custom policy?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I mean it depends on how we define this field and how user implements the policy. If user policy retried the request and succeeded, they might not consider that object as a failed count

Copy link
Contributor

Choose a reason for hiding this comment

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

You're right, thinking more about it, it's only if the retry policy also returns an error that this counts as failed.

However, I still think that we have an accurate count of failed get/uploads

  • If user provides standard policies, we are counting correctly
  • If user provides their own policies, and they successfully/unsuccessfully retry, we would still know whether it was successful or not depending on whether they return err or not

@wty-Bryant wty-Bryant force-pushed the feat-tmv2-audit branch 2 times, most recently from f2aee8a to 2bbe6ef Compare December 16, 2025 22:53
@wty-Bryant wty-Bryant merged commit 45b7607 into main Dec 19, 2025
16 of 17 checks passed
@wty-Bryant wty-Bryant deleted the feat-tmv2-audit branch December 19, 2025 16:13
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.

3 participants