* fix(protobuf-codegen): Fix protobuf import path with discriminator
This PR fixes a critical bug in the protobuf schema generator where models using discriminators with llOf composition were generating invalid import paths when child schemas contained references to other models.
* fix: Add missing element in OpenAPI discriminator test case
* feat(protobuf-generator): Improve protobuf generation
* Improve management of inheritance
* Improve management of discriminator
* Allow to separate inline enums in external files
* Add unit test
* fix: Improve logic when extracting enums to avoid collision in enum values
* fix: Manage case with Enum in lists
* fix: Fix issue on enum extraction
Fix issue linked to enum in array when there is inheritance or discriminator
* doc: Add documentation for new parameter
* chore: Update protobuf samples
---------
Co-authored-by: Anthony TODISCO <Anthony.TODISCO+amadeus@amadeus.com>
Wrap example values with escapeText() to properly escape special
characters in generated Go client code examples
Signed-off-by: Julien Pivotto <291750+roidelapluie@users.noreply.github.com>
* [R] avoid to-JSON issues when R6 classes contain lists of R6 classes
* fix missing comma
* only include extractor methods when they are needed
* regenerate samples
* fix typo
Add new OpenAPINormalizer rule SORT_MODEL_PROPERTIES that sorts schema
properties alphabetically by name. This ensures deterministic code
generation output regardless of property ordering in the source spec.
The rule:
- Uses TreeMap to sort properties by natural string order
- Applies at the OpenAPI normalization stage, working for all generators
- Is opt-in (defaults to false) to maintain backward compatibility
Usage:
openapi-generator generate --openapi-normalizer SORT_MODEL_PROPERTIES=true ...
Fixes non-deterministic property ordering that could cause spurious diffs
in generated code when the source schema order varies.
* [Rust] Update reqwest dependency to 0.13 with query and form features
Update the Rust client generator template to use reqwest 0.13 instead
of 0.12, as requested in issue #22621.
In reqwest 0.13, the `query()` and `form()` methods have been moved
behind feature flags and are disabled by default. Since the generated
Rust clients extensively use both methods, these features must be
explicitly enabled.
Changes:
- Updated all reqwest dependencies from ^0.12 to ^0.13
- Added "query" and "form" to reqwest feature flags for all variants:
- Blocking client configuration
- Async client with file stream support
- Async client without file stream
- Reqwest-trait variant
- Updated reqwest-middleware features for consistency
This maintains full backward compatibility as only the dependency
version and features change. The API surface of generated code
remains identical.
Fixes#22621
* [Rust] Updated samples
* [Rust] Rename rustls-tls feature to rustls to match reqwest 0.13
In reqwest 0.13, the rustls-tls feature was renamed to rustls.
This updates the Cargo.mustache template and all generated samples
to use the new feature name, fixing CI build failures when using
--all-features flag.
* [Rust] Upgrade reqwest-middleware to 0.5 for reqwest 0.13 compatibility
The previous reqwest-middleware 0.4 depends on reqwest 0.12, which caused
type conflicts when upgrading to reqwest 0.13:
- reqwest::Error (from reqwest 0.13)
- reqwest_middleware::reqwest::Error (from reqwest 0.12 via middleware)
These are different types from different versions of reqwest.
reqwest-middleware 0.5 is compatible with reqwest 0.13, resolving the
version conflict. With both using the same reqwest version, the re-exported
types are now correctly aligned.
* [Rust] Use query and form features from reqwest-middleware
It adds "query" and "form" features for reqwest-middleware crate in petstore-async-middleware example and Cargo.mustache template.
---------
Co-authored-by: Emil Bonne Kristiansen <emilbonnek@gmail.com>
* [BUG][typescript-angular] apiKeys cause service compilation errors
Updated TypeScript Angular `configuration.mustache` to properly handle
apiKeys in query parameters by using `OpenApiHttpParams` instead of
`HttpHeaders` to avoid compilation errors.
Fixes#22774
* add generated samples
* [swift6][client] Increase minimum supported SDK to accommodate swift concurrency
* [swift6][client] Increase minimum supported SDK to accommodate swift concurrency
* Fix HTML generator to display array types for body parameters
The HTML generator (htmlDocs) was not properly displaying array types
for request body parameters. When an endpoint accepted an array of
objects as input, only the base type was shown (e.g., "User") instead
of the full array type (e.g., "array[User]").
This fix updates the bodyParam.mustache template to include container
type information (array, map, etc.) when present, matching the format
already used for return types.
Before: User
After: array[User]
The fix wraps the baseType with containerType[...] when isContainer
is true, ensuring consistent type display across both input and output
types in the generated HTML documentation.
* Add html.yaml config and document testing requirements
Due to network limitations in the automated build environment, the
following steps could not be completed but are required per
contribution guidelines:
1. Build project: ./mvnw clean install -DskipTests
2. Regenerate samples: ./bin/generate-samples.sh bin/configs/html.yaml
3. Commit updated samples: git add samples/documentation/html/
Added:
- bin/configs/html.yaml: Configuration for html generator samples
- TESTING_STEPS.md: Detailed instructions for completing the PR
The template fix in bodyParam.mustache is complete and correct.
Sample regeneration is needed to verify the fix visually in the
generated HTML documentation.
* Add concrete example showing the bug location in current HTML sample
* Update HTML samples to verify array type fix
Regenerated samples/documentation/html/index.html to verify the array
type fix in bodyParam.mustache is working correctly.
Verified fix:
- Before: <div class="param">User <a href="#User">User</a> (required)</div>
- After: <div class="param">User array[<a href="#User">User</a>] (required)</div>
The createUsersWithArrayInput endpoint (and all array body parameters)
now correctly displays "array[Type]" instead of just "Type".
Also removed TESTING_STEPS.md as testing is now complete.
* Update VERSION to 7.20.0-SNAPSHOT to match project version
The samples were regenerated using npm's openapi-generator-cli (v7.4.0),
but the CI expects the VERSION to match the current development version
(7.20.0-SNAPSHOT). Updated to prevent CI failures.
---------
Co-authored-by: Claude <noreply@anthropic.com>
* Add support for other Accept header values or full arrays when multiple options are present.
* Expose ContentHeaders on ApiResponse, to access ContentDisposition for example with file downloads.
* Update samples and documentation
* Fix build warning in samples
* optionally skip parsing responses to R6 objects
* parse -> .parse
* scope .parse to endpoints that return data
* move handling of .parsed so that it applies to both primitive and non-primitive return types
* try, try, again
