-
Notifications
You must be signed in to change notification settings - Fork 192
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
Server streaming body #1023
Server streaming body #1023
Conversation
Hmm, I wonder why
|
wrap_stream is available only with the |
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.
This is amazing @guymguym !! I left a couple of comments, nothing major :)
...tware/amazon/smithy/rust/codegen/server/smithy/generators/ServerOperationHandlerGenerator.kt
Outdated
Show resolved
Hide resolved
...n/software/amazon/smithy/rust/codegen/server/smithy/protocols/ServerHttpProtocolGenerator.kt
Outdated
Show resolved
Hide resolved
...n/software/amazon/smithy/rust/codegen/server/smithy/protocols/ServerHttpProtocolGenerator.kt
Outdated
Show resolved
Hide resolved
...n/software/amazon/smithy/rust/codegen/server/smithy/protocols/ServerHttpProtocolGenerator.kt
Outdated
Show resolved
Hide resolved
...n/software/amazon/smithy/rust/codegen/server/smithy/protocols/ServerHttpProtocolGenerator.kt
Outdated
Show resolved
Hide resolved
...n/software/amazon/smithy/rust/codegen/server/smithy/protocols/ServerHttpProtocolGenerator.kt
Outdated
Show resolved
Hide resolved
...tware/amazon/smithy/rust/codegen/server/smithy/generators/ServerOperationHandlerGenerator.kt
Outdated
Show resolved
Hide resolved
...tware/amazon/smithy/rust/codegen/server/smithy/generators/ServerOperationHandlerGenerator.kt
Outdated
Show resolved
Hide resolved
...n/software/amazon/smithy/rust/codegen/server/smithy/protocols/ServerHttpProtocolGenerator.kt
Outdated
Show resolved
Hide resolved
...n/software/amazon/smithy/rust/codegen/server/smithy/protocols/ServerHttpProtocolGenerator.kt
Show resolved
Hide resolved
ac3eb3c
to
b87b7e9
Compare
...n/software/amazon/smithy/rust/codegen/server/smithy/protocols/ServerHttpProtocolGenerator.kt
Outdated
Show resolved
Hide resolved
b87b7e9
to
58ba708
Compare
80580c8
to
d57232d
Compare
d57232d
to
44d1379
Compare
44d1379
to
a4ff63f
Compare
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'd like to merge this PR this week.
I did another pass and only found one more nitpick.
I'm approving. Can you please merge and resolve conflicts?
@@ -132,13 +134,18 @@ class ServerOperationHandlerGenerator( | |||
} else { | |||
symbolProvider.toSymbol(operation.outputShape(model)).fullName | |||
} | |||
val streamingBodyTraitBounds = if (operation.inputShape(model).hasStreamingMember(model)) { | |||
"\n B: Into<#{SmithyHttpServer}::ByteStream>," |
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.
You can remove the \n
and interpolate the variable in the next line.
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.
@david-perez the reason I did this was that the output is usually not including this streaming member and then it generates an empty line, which is not causing any compilation issues, but is weird to watch...
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 run "cargo fmt" at the end of the codegen, so the weird look should go away.. Is it not?
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.
Nope, the empty line is still there. Perhaps because it's just an empty line then cargo fmt will not remove it.
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.
is there a better way to generate an optional line?
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.
Not that I know of. Maybe @rcoh knows.
...n/software/amazon/smithy/rust/codegen/server/smithy/protocols/ServerHttpProtocolGenerator.kt
Outdated
Show resolved
Hide resolved
I'll give this another pass this morning as well. |
a4ff63f
to
538d063
Compare
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.
Looks good!
@@ -132,13 +134,18 @@ class ServerOperationHandlerGenerator( | |||
} else { | |||
symbolProvider.toSymbol(operation.outputShape(model)).fullName | |||
} | |||
val streamingBodyTraitBounds = if (operation.inputShape(model).hasStreamingMember(model)) { | |||
"\n B: Into<#{SmithyHttpServer}::ByteStream>," |
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 run "cargo fmt" at the end of the codegen, so the weird look should go away.. Is it not?
25e8ede
to
9792c9c
Compare
@@ -525,14 +525,14 @@ class ServerProtocolTestGenerator( | |||
FailingTest(RestJson, "RestJsonSupportsNegativeInfinityFloatInputs", Action.Response), | |||
FailingTest(RestJson, "RestJsonStreamingTraitsWithBlob", Action.Request), | |||
FailingTest(RestJson, "RestJsonStreamingTraitsWithNoBlobBody", Action.Request), | |||
FailingTest(RestJson, "RestJsonStreamingTraitsWithBlob", Action.Response), |
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.
@david-perez @crisidev I was not sure what to do here - should I remove these tests from the expect-fail list as these now seem to pass...?
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.
Yep, if it passes it can be removed from the failing list.
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.
@guymguym I manually verified the now-passing tests and they look good.
I also had a look at the remaining failing request streaming protocol tests and pushed a new commit to this branch, Add blob streaming support for server request protocol tests, to get rid of them.
The only remaining failing protocol test for streaming is RestJsonStreamingTraitsRequireLengthWithBlob
, but that is due to us not setting Content-Length
appropriately, so I've cut #1146 to track that.
Let me know if you agree with the fix or have any questions.
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.
That's great @david-perez. Thank you for making it so easy!
9792c9c
to
bc571b3
Compare
if (parsedValue != null) { | ||
withBlock("input = input.${member.setterName()}(", ");") { | ||
parsedValue(this) | ||
if (streamingMember == null) { |
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 wanted to highlight this condition I added - I had to check it so that with streaming there will be no bindings parsers generated. The weird thing is just the flow of this function - the conditions seems a bit detached from one another but I wasn't sure if there's a way to simplify:
if (parser != null) { ... }
else if (streamingMember != null) { ... }
if (streamingMember == null) { ... }
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.
@guymguym Thanks for calling this out. We still need to generate HTTP bindings for blob streaming (e.g. HTTP header bindings). This also led me to discover there's a bug in Smithy that is now being fixed over at smithy-lang/smithy#1075
I have pushed a new commit to this branch, Move blob streaming handling to httpPayload binding generation, that refactors this part and generates the stream handling when we handle @httpPayload
.
Let me know if you agree with the fix or have any questions.
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.
Ah now I see. I think my problem was probably that the previous headers code that I used was not very accurate, but since your PR to implement server response headers that might have fixed this issue. I will test a bit later and report back if I still see any issues in the S3 server codegen, but it looks good to me. Thanks!
@david-perez I'm done rebasing and updating. Couple questions for you in the comments above. Thanks |
3722ea5
to
d5e4174
Compare
0033f7e
to
9b268db
Compare
One last thought: given that we decided on using |
3f6c996
to
2ca7cc0
Compare
done @david-perez |
FailingTest(RestJson, "RestJsonSupportsNaNFloatInputs", Action.Response), | ||
FailingTest(RestJson, "RestJsonSimpleScalarProperties", Action.Response), | ||
FailingTest(RestJson, "RestJsonSupportsInfinityFloatInputs", Action.Response), | ||
FailingTest(RestJson, "RestJsonSupportsNegativeInfinityFloatInputs", Action.Response), |
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.
@david-perez These seem to fail in CI - did I accidentally add these changes when rebasing from main?
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, earlier today I had pushed to this branch a commit merging from main
907c0f3 (which removes these now-passing tests), so that you wouldn't have to deal with conflicts.
But you didn't fetch it (?), and you force-pushed the latest commit.
In general once a PR is open I think it's best to not rebase and force-push, only merge from main. Because AFAIK GitHub's UI won't show the previous history, only the rewrriten one, and that might confuse other people looking at the PR. The downside is that merging makes the history non-linear, but we always squash before merging, so I think it's a small price to pay for having an entire's PR history.
Anyway, these tests can be removed from the failing list.
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.
got it. thanks. pushed a commit to remove those.
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 think it's good now
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.
Approved on the client side
@guymguym Thank you! |
Signed-off-by: Guy Margalit [email protected]
Motivation and Context
Description
Testing
Generated s3 server codegen and tested get-object/put-object with streams.
Checklist
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
CC @crisidev @david-perez