Unable to perform multipart upload after upgrade: current throughput: 0 B/s is below minimum: 1 B/s #1146
Labels
bug
This issue is a bug.
closed-for-staleness
p1
This is a high priority issue
response-requested
Waiting on additional info and feedback. Will move to 'closing-soon' in 7 days.
Comments
DimanNe
added
bug
|
Same error with |
aajtodd
added
p1
|
Thanks for the issue, we are looking into this now and how best to address it. As a workaround you can disable let config = aws_config::defaults(aws_config::BehaviorVersion::latest())
.stalled_stream_protection(
StalledStreamProtectionConfig::enabled()
.upload_enabled(false)
.build(),
)
.load()
.await;This will keep stalled stream protection for downloads enabled and only disable uploads (which was the default prior to let config = aws_config::defaults(aws_config::BehaviorVersion::latest())
.stalled_stream_protection(StalledStreamProtectionConfig::disabled())
.load()
.await; |
github-merge-queue bot
pushed a commit
to smithy-lang/smithy-rs
that referenced
this issue
May 17, 2024
…lete (#3644) ## Motivation and Context <!--- Why is this change required? What problem does it solve? --> <!--- If it fixes an open issue, please link to the issue here --> * awslabs/aws-sdk-rust#1141 * awslabs/aws-sdk-rust#1146 * awslabs/aws-sdk-rust#1148 ## Description * Disables stalled stream upload protection for requests with an empty/zero length body. * Disables stalled stream upload throughput checking once the request body has been read and handed off to the HTTP layer. ## Testing Additional integration tests added covering empty bodies and completed uploads. Tested SQS issue against latest runtime and can see it works now. The S3 `CopyObject` issue is related to downloads and will need a different solution. ## Checklist <!--- If a checkbox below is not applicable, then please DELETE it rather than leaving it unchecked --> - [x] I have updated `CHANGELOG.next.toml` if I made changes to the smithy-rs codegen or runtime crates - [x] I have updated `CHANGELOG.next.toml` if I made changes to the AWS SDK, generated SDK code, or SDK runtime crates ---- _By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice._ --------- Co-authored-by: Zelda Hessler <[email protected]> Co-authored-by: ysaito1001 <[email protected]>
|
We just released the runtime crate updates: https://github.com/smithy-lang/smithy-rs/releases/tag/release-2024-05-21 |
|
Let us know whether today's release has improved the behavior of your use case. |
Velfi
added
the
response-requested
|
Greetings! It looks like this issue hasn’t been active in longer than a week. We encourage you to check if this is still an issue in the latest release. Because it has been longer than a week since the last update on this, and in the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please feel free to provide a comment or add an upvote to prevent automatic closure, or if the issue is already closed, please feel free to open a new one. |
github-actions
bot
added
closing-soon
|
Hi Folks, unfortunately latest update didn't resolve the issue. Large multi-part uploads still fail in the same way on the slow-ish internet: |
kolupaev
pushed a commit
to kolupaev/distill-cli
that referenced
this issue
Aug 16, 2024
When uploading large videos to the s3 bucket (~200mb) on a slow uplink (2 Mb/s) a stall protection for upload kick in. This protection incorrectly detects stalled upload and panics, even on active uploads healthy uploads. See awslabs/aws-sdk-rust#1146 Crate changes: - add log and env_logger to aid debugging and root causing - update aws-sdk to latest Testing: RUST_LOG=debug cargo run -- -i "~/Downloads/meeting.mp4" -o text
jbnunn
pushed a commit
to awslabs/distill-cli
that referenced
this issue
Sep 3, 2024
When uploading large videos to the s3 bucket (~200mb) on a slow uplink (2 Mb/s) a stall protection for upload kick in. This protection incorrectly detects stalled upload and panics, even on active uploads healthy uploads. See awslabs/aws-sdk-rust#1146 Crate changes: - add log and env_logger to aid debugging and root causing - update aws-sdk to latest Testing: RUST_LOG=debug cargo run -- -i "~/Downloads/meeting.mp4" -o text Co-authored-by: kolupaev <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
After this upgrade:
multi-part upload started to fail with the following messages in logs:
Same code works perfectly fine with the older version.
Expected Behavior
see above
Current Behavior
see above
Reproduction Steps
see above
Possible Solution
No response
Additional Information/Context
No response
Version
Environment details (OS name and version, etc.)
Linux
Logs
No response
The text was updated successfully, but these errors were encountered: