fix(rust): correctly handle anyOf with inline primitives #22072
+87 −57
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
wing328 reviewed Oct 20, 2025
| return mdl; | ||
| } | ||
| | ||
| private void processComposedSchemas(Schema model, CodegenModel mdl, String type) { |
There was a problem hiding this comment.
thanks for the PR
what about adding some comments (e.g. docstring, inline comments) for this function?
wing328 reviewed Oct 20, 2025
| } | ||
| {{/anyOf.isEmpty}} | ||
There was a problem hiding this comment.
Do we need the same fix for oneOf block below (around line 220) ?
| thanks for the PR can you please merge #21911 contains some tests for anyOf) into your branch? |
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge. Suggestion cannot be applied right now. Please check back later.
Pull Request: Fix Rust generator issue with anyOf field naming conflicts
Description
This PR fixes a bug in the Rust client generator where an
anyOffield in a response body that has the same name as a request parameter generates an empty struct instead of the expected type or enum. This issue occurs whether theanyOfcontains a single variant or multiple variants.The fix ensures that:
anyOffields with a single primitive type variant, the generated Rust struct uses the expected primitive type (e.g.,Option<String>), instead of generating an empty struct wrapper.anyOffields with multiple variants, the generator produces the expected Rust enum variant types.This resolves the issue reported in [#22042](#22042) and was validated by running the generator against the minimal repro spec from the issue. The output matches the expected Rust struct and enum definitions.
How to verify
mvn clean install -DskipTests -pl modules/openapi-generator-cli -amto build the CLI module after applying the patch.anyOffield no longer produces empty structs but the appropriate primitive type or enum.Related issue
Fixes #22042
PR checklist
Read the [contribution guidelines](https://github.com/openapitools/openapi-generator/blob/master/CONTRIBUTING.md).
Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work.
Ran the following to build the project and update samples:
Committed all changed files, including regenerated samples.
Targeted the
masterbranch.Linked the PR to the issue using “Fixes [BUG] [RUST] Empty field structs generated when name conflict between path parameter and response object field of same name using anyOf #22042 ”.
Mentioned relevant technical committee members for Rust generator review: @frol (2017/07) @farcaller (2017/08) @richardwhiuk (2019/07) @paladinzh (2020/05) @jacob-pro (2022/10) @dsteeley (2025/07)