Matt Jurik

I believe this might have been reported before, but it was closed without a solid repro case: https://github.com/awslabs/aws-sdk-rust/issues/453 Notably, I don't think the whole file is being buffered into memory,...

Depending on the memory allocator behavior, the usage may not return to pre-upload levels (even if all memory is properly free'd by the application code and there is no leak)....

Confirmed that using hyper-rustls 0.23.0 fixes the high-memory issue. Huge thanks for hunting this down @jdisanti!

I'll +1 this. This is a pretty ugly performance wart. Our team has independently hit this issue twice, where some singular task takes longer than the developer expects and this...

This feels somewhat similar to Spectre and Meltdown where Intel was "caught speeding" -- their optimizations were too aggressive for the happy-path (i.e. CPU only loaded with trusted, well-behaved programs)...

Was finally able to capture some TRACE-level logs around the time we observe the partial response. [log.txt](https://github.com/awslabs/aws-sdk-rust/files/14579874/log.txt)

> Do you have a sense of what "sometimes" is here? 1%? 0.1%? 0.001%? We don't have good metrics on this, but I'll estimate this somewhere at Are you connecting...

+1. For reference, the slow release cadence is annoying for organizations who wish to publish crates that depend on rust-rocksdb and want to use any of the improvements in the...

> Currently, Tokio relies on well-behaved application behavior, including tasks completing their polls in a reasonable time. It may be worth trying to further define what "well-behaved application behavior" actually...