feat(rust-client): Add file variant with more reliable batching#346
feat(rust-client): Add file variant with more reliable batching#346
Conversation
Semver Impact of This PR🟡 Minor (new features) 📋 Changelog PreviewThis is how your changes will appear in the changelog. New Features ✨
🤖 This preview updates automatically when you update the PR. |
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
jan-auer
left a comment
jan-auer
left a comment
There was a problem hiding this comment.
We should also support this in Python, for completeness.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
| // _ => todo!("compression algorithms other than `zstd` are currently not supported"), | ||
| (None, PutBody::File(file)) => { | ||
| let stream = ReaderStream::new(file).boxed(); | ||
| Body::wrap_stream(stream) |
There was a problem hiding this comment.
Missing BufReader for unbuffered file read path
Medium Severity
The (None, PutBody::File(file)) branch wraps the file directly in ReaderStream::new(file) without a BufReader, while the (Some(Compression::Zstd), PutBody::File(file)) branch correctly uses BufReader::new(file). Since tokio::fs::File dispatches every poll_read call to the blocking thread pool, skipping BufReader means each 4KB chunk triggers a separate thread pool dispatch. For large files, this roughly doubles the number of blocking dispatches compared to the buffered path.
Additional Locations (1)
2 participants
Currently, the
manyAPI doesn't take into account body sizes, but the server does.This means that if a user tries to upload large objects using that API, operations would just fail as the server-side limit is enforced.
This adds a new variant to
PutBodythat represents a file, and special handling logic in themanyAPI based on this variant that prevents PUT failures by inspecting the file size and falling back to single-object PUT requests when said size exceeds the limit.Note that this is slightly on the conservative side, as we rely on the file size on the file system prior to compression.
Similar handling can be introduced in the future for the other variants of
PutBody, which would necessary include buffering for streams.