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

[jacob-mink-1996]

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

1. text/event-stream responses
2. 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:

1. I wrote some unit tests that verify that the right types and names are present
2. 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)

[linxGnu]

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

[jacob-vincent-mink]

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

[linxGnu]

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]

@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

[jacob-mink-1996]

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

[linxGnu]

I don't think we should remove:

#[derive(Debug, PartialEq, Serialize, Deserialize)]

[jacob-vincent-mink]

Interesting constraint @linxGnu - the problem is that by introducing Box<impl Stream…> to the enum, we lost the ability to derive these always. I even generated a custom Debug implementation of a stream type is present in the enum.

Additionally, all of them except for Debug are technically unused. The result enums are not serialized, it is the thing inside them that is (sometimes) serialized (which we already know implements Deserialize and Serialize because it was generated as such).

I’m not sure it is possible to leave them in like you suggest if Box<impl Stream…> is what we use. Plus, forcing the stream to be + Debug + Serialize + Deserialize will not work with many stream/async stream libraries as they typically return an opaque Stream type.

[linxGnu]

@jacob-mink-1996
You should use conditional in Mustache. Something like this:

{{^stream}} #[derive(..., Serialize, Deserialize)] {{/stream}} {{#stream}} #[derive(Debug)] {{/stream}} 

[jacob-vincent-mink]

Is the value in including them purely because it was done that way before? The Serializer, Deserialize, PartialEq, and Eq traits are not leveraged on these types anywhere in the generated source.

Anyway, I’ll fix that up tomorrow for you.