Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(s3): make leavePartsOnError default to true #4414

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

mifi
Copy link

@mifi mifi commented Feb 7, 2023

Issue

Issue number, if available, prefixed with "#"

#2311

Description

Changes the unsafe default leavePartsOnError to true. The default would leave the upload corrupt without anyone knowing.

Testing

How was this change tested?

Additional context

Add any other context about the PR here.


By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@mifi mifi requested a review from a team as a code owner February 7, 2023 09:45
@mifi mifi changed the title Main fix(s3): make leavePartsOnError default to true Feb 7, 2023
@@ -21,7 +21,7 @@ try {
], // optional tags
queueSize: 4, // optional concurrency configuration
partSize: 1024 * 1024 * 5, // optional size of each part, in bytes, at least 5MB
leavePartsOnError: false, // optional manually handle dropped parts
leavePartsOnError: true, // optional throw error on failed parts

Choose a reason for hiding this comment

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

I think this flag name is confusing. I'm bad with naming but maybe change it to something like

Suggested change
leavePartsOnError: true, // optional throw error on failed parts
throwOnPartsError: true, // optional throw error on failed parts

Copy link
Author

Choose a reason for hiding this comment

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

I agree it's a bad name, but that would be an even more breaking change. maybe a todo for the future?

Choose a reason for hiding this comment

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

Yes, you're right

@RanVaknin
Copy link
Contributor

Hi there @mifi ,

As mentioned in the comments, changing the name for this config type would be considered a breaking change and not something we can merge.

Can you amend the PR to be a documentation change only?

Thanks,
Ran~

@RanVaknin RanVaknin added the response-requested Waiting on additional info and feedback. Will move to \"closing-soon\" in 7 days. label Apr 10, 2024
@mifi
Copy link
Author

mifi commented Apr 10, 2024

Hi. I didn't change the name of the variable, just the default value from false to true. do you also consider that a breaking change? I would argue it's not, and that it's rather a bug fix because the default value false leads to such a broken behaviour.

@github-actions github-actions bot removed the response-requested Waiting on additional info and feedback. Will move to \"closing-soon\" in 7 days. label Apr 11, 2024
@RanVaknin
Copy link
Contributor

Hi @mifi ,

The change in behavior would be considered a breaking change since certain customers might rely on the "incorrect" behavior.

I'll need to discuss this with the team once again to see if we are willing to accept this and cause a "breaking fix".

Thanks,
Ran~

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.

None yet

3 participants