[rust-axum] Add support for multiple response types and streaming responses#22095
[rust-axum] Add support for multiple response types and streaming responses#22095jacob-mink-1996 wants to merge 5 commits intoOpenAPITools:masterfrom
Conversation
… stream and resposne enums Keep going, there are tests failing Remove the "single item" legacy support and wrap it in the multipart content umbrella Functional testing (with a test that can be uncommented to actually test building code if cargo is available) Fixing the box/pin for the stream to behave well in real code Cleanup unused extensions Clean up the operations Ensure the stream info propagates to other parts of the generator Cleanup tests
bcc335f to
e95ced8
Compare
|
@jacob-mink-1996 just fyi, I will have a look this weekend |
|
Sorry, I wasn’t able to review your PR last weekend due to some bug fixes for Rust Axum. I’ll focus on it this weekend and appreciate your patience. |
|
In the meantime, could you please run integration test, using following command: mvn clean && ./bin/generate-samples.sh bin/configs/manual/rust-axum-* && mvn integration-test -f samples/server/petstore/rust-axum/pom.xml |
|
Nice, thank you @linxGnu. I ran the integration tests and discovered some issues with responses that did not have a content-type. Updated the code to render these properly. My API spec output was unaffected by the change, but the integration test outputs had a bunch of updates, which I have committed (I think these are from the original set of changes, anyway). |
linxGnu
left a comment
There was a problem hiding this comment.
I will continue reviewing your PR. At the moment, I have one concern below
…erialize, and PartialEq on the response enum
| {{#x-produces-json}} | ||
| {{#x-serializer-json}} | ||
| {{^allowBlockingResponseSerialize}} | ||
| let body_clone = body.clone(); |
There was a problem hiding this comment.
@jacob-mink-1996
Could you please explain why we need body clone?
There was a problem hiding this comment.
Good point, looks unused. I must have added it while playing with the stream lifetime. I’ll get rid of this.
| } else { | ||
| producesFormUrlEncoded = false; | ||
| producesPlainText = false; | ||
| } |
There was a problem hiding this comment.
@jacob-mink-1996
I think the PR is too big to review. How about support streaming responses only? Support multiple response type in another PR?
There was a problem hiding this comment.
It might only be large because of the integration tests changed - lots of response enums have new names to support e.g. a 200 with two different content types.
I don’t have time at the moment to dedicate toward splitting the change, and again, am still unfamiliar with the repository. I do not know what exists/does not exist that should be done beyond slapping down some unit test yaml :)
Perhaps this PR should be used as inspiration if you would like to implement one or both of those features in isolation?
There was a problem hiding this comment.
Hi @jacob-mink-1996
I’m also hoping to find some time this week or next to work on this feature. l will be pushing commits here and we can work together.
There was a problem hiding this comment.
Awesome @linxGnu. That makes me feel a lot better. I can wait until you get your hands dirty before I try to split the features if you still want that.
Just to point it out - the reason I went down the route of coupling these features was that introducing another Boolean check for isStream in the vendor features made things unwieldy - just using the list directly with checks seemed to clean things up, and then this followed naturally.
| schema: | ||
| oneOf: | ||
| - $ref: '#/components/schemas/Dog' | ||
| - $ref: '#/components/schemas/Cat' |
There was a problem hiding this comment.
Missing Integration Test for this specs. You should register one here:
https://github.com/OpenAPITools/openapi-generator/tree/master/bin/configs/manual
|
Hello! We are in need of this fix and I was wondering if @jacob-mink-1996 (@jacob-vincent-mink ?) had plans to finish this or if I could pick this up? |
All yours if you want it (and both are me) - lost bandwidth for this one, but would love to see the feature land. |
This change enables two related features in the rust-axum server generator
The core of the feature is to iterate over the content types rather than taking just the first, then build up a new list in the vendor extensions that includes the appropriate information. I took the approach of still keeping the templates simple and tried to compute types in the Java code as much as possible - we could of course go the other way and expand the type within the template, but it got pretty gnarly.
@linxGnu - I adopted a bit of a hybrid approach to the typing we discussed since this isn't just a return type change, it changes the enums. I went ahead and used a
(along with appropriate Sends/Syncs/'static annotations). This allowed me to shove it in an enum, and it appears to play nice with other methods that return an
impl Streamorimpl TryStream, both of which can be coerced into the pin-box using the.boxed()method fromStreamExt.Finally, the templates are updated to support the new code gen. I have validated this two ways:
PR checklist
Commit all changed files.
This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
These must match the expectations made by your contribution.
You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example
./bin/generate-samples.sh bin/configs/java*.IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
master(upcoming7.x.0minor release - breaking changes with fallbacks),8.0.x(breaking changes without fallbacks)"fixes #123"present in the PR description)fixes [REQ] [rust-axum] support text/event-stream #21967
@frol (2017/07) @farcaller (2017/08) @richardwhiuk (2019/07) @paladinzh (2020/05) @jacob-pro (2022/10) @dsteeley (2025/07)