Note this slightly changes the meaning as well, this number goes up and down, and it's never more than 1 for async-streaming.
This fixes a bug when resuming an upload. We'd forgot to increment the old num_parts_read along with num_parts_started and num_parts_completed which threw off the math and lead to the upload stalling. It seemed simpler and more obvious to just track the number we care about, rather than have so many different numbers ticking up, from many different locations, and their meaning is weird when skipping is involved.
If a stream-reading failure occurs during "resume from pause", reveal the actual error code. Stop covering it with AWS_ERROR_S3_RESUME_FAILED.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
num_parts_started
, for claritynum_parts_pending_read
.num_parts_read
along withnum_parts_started
andnum_parts_completed
which threw off the math and lead to the upload stalling. It seemed simpler and more obvious to just track the number we care about, rather than have so many different numbers ticking up, from many different locations, and their meaning is weird when skipping is involved.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.