[rust-axum] Add support for multiple response types and streaming responses #22095

jacob-mink-1996 · 2025-10-09T14:02:29Z

This change enables two related features in the rust-axum server generator

text/event-stream responses
multi-part responses (e.g. 200: application/json & text/event-stream)

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

Pin<Box<dyn Stream<Item = Result<..., Box<dyn Error>>>>>

(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 Stream or impl TryStream, both of which can be coerced into the pin-box using the .boxed() method from StreamExt.

Finally, the templates are updated to support the new code gen. I have validated this two ways:

I wrote some unit tests that verify that the right types and names are present
I ran this generator on the real project I'm working on that uses this and have been able to refactor my code based on this new support nicely.

PR checklist

Read the contribution guidelines.
Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
Run the following to build the project and update samples:
```
./mvnw clean package || exit
./bin/generate-samples.sh ./bin/configs/*.yaml || exit
./bin/utils/export_docs_generators.sh || exit
```
(For Windows users, please run the script in WSL)
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.
File the PR against the correct branch: master (upcoming 7.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
If your PR solves a reported issue, reference it using GitHub's linking syntax (e.g., having "fixes #123" present in the PR description)
fixes [REQ] [rust-axum] support text/event-stream #21967
If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

@frol (2017/07) @farcaller (2017/08) @richardwhiuk (2019/07) @paladinzh (2020/05) @jacob-pro (2022/10) @dsteeley (2025/07)

… 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

linxGnu · 2025-10-10T01:11:03Z

@jacob-mink-1996 just fyi, I will have a look this weekend

jacob-vincent-mink · 2025-10-21T15:53:20Z

Thanks @wing328, @linxGnu - any actions on me so far? Just checking in to make sure we don't go stale.

linxGnu · 2025-10-22T00:51:12Z

Hi @jacob-mink-1996

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.

linxGnu · 2025-10-22T00:57:10Z

@jacob-mink-1996

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

…types as simple enums

jacob-mink-1996 · 2025-10-22T02:13:18Z

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

I will continue reviewing your PR. At the moment, I have one concern below

modules/openapi-generator/src/main/resources/rust-axum/response.mustache

…erialize, and PartialEq on the response enum

linxGnu · 2025-10-27T00:27:46Z

modules/openapi-generator/src/main/resources/rust-axum/server-operation.mustache

-{{#x-produces-json}}
+{{#x-serializer-json}}
  {{^allowBlockingResponseSerialize}}
+                                                  let body_clone = body.clone();


@jacob-mink-1996
Could you please explain why we need body clone?

Good point, looks unused. I must have added it while playing with the stream lifetime. I’ll get rid of this.

linxGnu · 2025-10-27T00:53:25Z

...penapi-generator/src/main/java/org/openapitools/codegen/languages/RustAxumServerCodegen.java

-                    } else {
-                        producesFormUrlEncoded = false;
-                        producesPlainText = false;
-                    }


@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?

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?

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.

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.

linxGnu · 2025-10-27T00:58:01Z

modules/openapi-generator/src/test/resources/3_1/rust-axum/test-oneof-response.yaml

+              schema:
+                oneOf:
+                  - $ref: '#/components/schemas/Dog'
+                  - $ref: '#/components/schemas/Cat'


Missing Integration Test for this specs. You should register one here:
https://github.com/OpenAPITools/openapi-generator/tree/master/bin/configs/manual

jacob-mink-1996 force-pushed the jmink/support-multiple-response-types branch from bcc335f to e95ced8 Compare October 9, 2025 16:34

wing328 added Enhancement: Feature Server: Rust labels Oct 20, 2025

jacob-mink-1996 added 2 commits October 21, 2025 21:10

Updates on running integration tests - need to handle empty response …

4454b78

…types as simple enums

Commit the changes to the generated rust code with the new feature

37f3e75

linxGnu suggested changes Oct 24, 2025

View reviewed changes

modules/openapi-generator/src/main/resources/rust-axum/response.mustache Show resolved Hide resolved

jacob-mink-1996 added 2 commits October 25, 2025 12:23

If there is no stream content, ensure we derive Debug, Serialize, Des…

684fbba

…erialize, and PartialEq on the response enum

Update the samples from the new condition derive generation

4645ebf

linxGnu suggested changes Oct 27, 2025

View reviewed changes

Uh oh!

Uh oh!

[rust-axum] Add support for multiple response types and streaming responses #22095

Are you sure you want to change the base?

[rust-axum] Add support for multiple response types and streaming responses #22095

Uh oh!

Conversation

jacob-mink-1996 commented Oct 9, 2025

PR checklist

Uh oh!

linxGnu commented Oct 10, 2025

Uh oh!

jacob-vincent-mink commented Oct 21, 2025

Uh oh!

linxGnu commented Oct 22, 2025

Uh oh!

linxGnu commented Oct 22, 2025

Uh oh!

jacob-mink-1996 commented Oct 22, 2025

Uh oh!

linxGnu left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

linxGnu Oct 27, 2025

Choose a reason for hiding this comment

Uh oh!

jacob-vincent-mink Oct 27, 2025

Choose a reason for hiding this comment

Uh oh!

linxGnu Oct 27, 2025

Choose a reason for hiding this comment

Uh oh!

jacob-vincent-mink Oct 27, 2025

Choose a reason for hiding this comment

Uh oh!

linxGnu Oct 27, 2025

Choose a reason for hiding this comment

Uh oh!

jacob-vincent-mink Oct 27, 2025

Choose a reason for hiding this comment

Uh oh!

linxGnu Oct 27, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants