-
Notifications
You must be signed in to change notification settings - Fork 190
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
Remove futures_core::stream::Stream
from aws_smithy_http::byte_stream::ByteStream
#2983
Remove futures_core::stream::Stream
from aws_smithy_http::byte_stream::ByteStream
#2983
Conversation
This commit responses to #2978 (comment)
A new generated diff is ready to view.
A new doc preview is ready to view. |
A new generated diff is ready to view.
A new doc preview is ready to view. |
A new generated diff is ready to view.
A new doc preview is ready to view. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems pretty reasonable. I might consider putting the impl Stream
bridge in the types-convert crate instead so customers can easily use it if they want
This commit addresses #2978 (comment)
This commit addresses #2978 (comment)
…aito/remove-futures-stream-from-byte-stream
The For external customers' use cases for |
A new generated diff is ready to view.
A new doc preview is ready to view. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome work on this!! I love how narrow this PR ended up being
codegen-core/src/main/kotlin/software/amazon/smithy/rust/codegen/core/smithy/RuntimeType.kt
Show resolved
Hide resolved
...tware/amazon/smithy/rust/codegen/server/smithy/protocols/ServerHttpBoundProtocolGenerator.kt
Show resolved
Hide resolved
This commit addresses #2978 (comment)
This commit addresses #2978 (comment)
This commit addresses #2978 (comment)
…aito/remove-futures-stream-from-byte-stream
This commit addresses #2983 (comment)
This commit addresses #2983 (comment)
This commit addresses #2983 (comment)
This commit addresses #2983 (comment)
A new generated diff is ready to view.
A new doc preview is ready to view. |
The method in question is used by the python server's custom `ByteStream` so it needs to be `pub`.
A new generated diff is ready to view.
A new doc preview is ready to view. |
@@ -393,7 +423,9 @@ impl ByteStream { | |||
/// # } | |||
/// ``` | |||
pub fn into_async_read(self) -> impl tokio::io::AsyncRead { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Earlier we could do this wrapping ourselves & since tokio_util::io::StreamReader
implements AsyncBufRead
, we would get a buffered reader for free. Would it be acceptable to change this to:
pub fn into_async_read(self) -> impl tokio::io::AsyncRead { | |
pub fn into_async_read(self) -> impl tokio::io::AsyncBufRead { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or perhaps you would want a separate into_async_buf_read
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have any buffering in our implementation. You should be able to wrap the ByteStream with a new-type and implement Stream for it to get the same functionality you used to have. The Stream impl should be a simple call through to the poll_next and size_hint methods.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I know. What I'm saying is that in this function, you're wrapping bytestream in StreamReader
from tokio, which implements AsyncBufRead
. So you could also return impl AsyncBufRead
from this function.
Otherwise, one has to wrap this in a BufReader
for no reason, since it is not possible to wrap ByteStream
in StreamReader
easily (without wrapping & implementing Stream manually).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I see what you're saying. Yeah, I don't see why we couldn't have two methods. You're welcome to submit a PR to add that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say it makes more sense to change the signature of the existing function as I suggested above. It won't be a breaking change at all since AsyncBufRead is a super trait of AsyncRead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good.
## Motivation and Context The tokio `StreamReader` implements `AsyncBufRead`, but we're returning `AsyncRead` currently. If a user needs an `AsyncBufRead`, then they've to wrap the returned value in tokio `BufReader` for no reason. Since `ByteStream` doesn't implement `Stream` anymore, one has to either wrap the returned value unnecessarily or write a wrapper similar to this function. See #2983 (comment). ## Description Simply changed the return type to say `impl AsyncBufRead`. Since `AsyncBufRead` is a super-set of `AsyncRead`, this is not a breaking change. ## Testing The code example tests it. ## Checklist - [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: Russell Cohen <rcoh@amazon.com>
Motivation and Context
Removes
futures_core::stream::Stream
fromaws_smithy_http::byte_stream::ByteStream
Description
This PR is part of our ongoing effort, #2413. We remove the
futures_core::stream::Stream
trait fromaws_smithy_http::byte_stream::ByteStream
. To continue support existing places that relied uponByteStream
implementing theStream
trait, we provide explicit.next
,.try_next
, and.size_hints
methods on that type. As part of it, a doc-hidden typeFuturesStreamCompatByteStream
, which implementsStream
, has been added toaws_smithy_http
to cater to those who need a type implementingStream
(see discussion why doc-hidden).Another place we need to update is codegen responsible for rendering stream payload serializer, and this affects the server. The regular server and the python server have slightly different rendering requirements, since the former uses
aws_smithy_http::byte_stream::ByteStream
(that does not implement theStream
trait) and latter uses its own ByteStream (that does implementStream
). We useServerHttpBoundProtocolCustomization
to handle the difference:StreamPayloadSerializerCustomization
andPythonServerStreamPayloadSerializerCustomization
.Testing
No new behavior has been added, relied on the existing tests in CI.
Checklist
CHANGELOG.next.toml
if I made changes to the smithy-rs codegen or runtime cratesCHANGELOG.next.toml
if I made changes to the AWS SDK, generated SDK code, or SDK runtime cratesBy submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.