feat(core): add splitOperationsByContentType option to divide operati…

[AntoineDuComptoirDesPharmacies]

This PR adds an opt-in splitOperationsByContentType option that fixes#6708: an operation may expose several request and/or response content-types with different schemas, but generators currently keep only the first one ("Multiple schemas found in the OAS 'content' section, returning only the first").
The result is a single, mistyped method, and the other content-types are unreachable.

The same underlying problem has been reported and worked around in a language-specific way in several places — e.g. #22095 (rust-axum), #8431 (Ruby), #13426 (TypeScript/Angular) and #10973 (Python request bodies). This PR addresses it generically in the core instead of per-generator.

The implementation is inspired by #19473, where operations were divided by content-type. The key difference here: the division is gated behind an opt-in option (splitOperationsByContentType, default false), so all existing generator outputs are unchanged and no current codegen is broken.

Why it is off by default

Some dynamically- or structurally-typed languages can already represent several input/return types within a single operationId, so splitting would be unnecessary (or even undesirable) for them:

• Python deserializes the response body from the actual Content-Type at runtime and returns a dynamically-typed object (see Adds request body content data to allow multiple content types to be sent to servers #10973 / Adds python-experimental which uses dynamic base classes #8325).
• Ruby maps the status / content-type to the return type at runtime in a single method ([Ruby] Incorrect return types if multiple responses are defined (reopened) #8431).
• TypeScript expresses it as a union return type, e.g. TypeA | TypeB, in a single method signature ([TS][Angular] better handling of multiple responses #13426).

Statically-typed / compiled languages (Java, C#, Go, Kotlin, Swift, ...) cannot overload a method by return type, so they benefit from one typed method per content-type — which is exactly what this option produces when enabled. Keeping it opt-in lets each consumer decide, without changing any default
output.

How it works

When the option is enabled, DefaultCodegen#preprocessOpenAPI divides an eligible operation into the cartesian product of its request-body and success-response content-types (deduplicated by schema). Each variant is a narrowed OpenAPI Operation (a single content-type on each axis) with a typed,
collision-free operationId — request appends With<Subtype> and response appends As<Subtype> (e.g. createReportWithXmlAsPdf). The variants are stored on the original operation under the x-content-type-variants extension and expanded by DefaultGenerator#processOperation, so each one re-enters
fromOperation and is typed natively by the target generator. The feature is therefore language-neutral: no per-language type re-derivation and no template changes.

Tests

Added unit tests in DefaultCodegenTest: the request×response cartesian (4 variants), the response-only case (2 variants), and a check that unambiguous operations are left untouched.

PR checklist

• [ X ] Read the contribution guidelines.
• [ X ] 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.
• [ X ] If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

Technical committee mention

This feature is opt-in and primarily benefits statically-typed / compiled generators, which cannot overload a method by return type and therefore gain one typed method per content-type. cc the relevant technical committee members:

• Java: @bbdouglas@sreeshas@jfiala@lukoyanov@cbornet@jeff9finger@karismann@Zomzog@lwlee2608@martin-mfg
• Java Spring: @cachescrubber@welshm@MelleD@atextor@manedev79@javisst@borsch @banlevente
• Kotlin: @andrewemery@4brunu @yutaka0m @stefankoppier@e5l@dennisameling
• C#: @mandrean@shibayan@Blackclaws@lucamazzanti@iBicha
• Go: @antihax@grokify@kemokemo@jirikuncar@ph4r5h4d@lwj5
• Rust: @frol@farcaller@richardwhiuk@paladinzh@jacob-pro@dsteeley
• Swift: @jgavris@ehyche@Edubits@jaz-ah@dydus0x14
• C++: @ravinikam@stkrwork@etherealjoy@MartinDelille @muttleyxd @aminya
• C: @zhemant @ityuhui @michelealbano @eafer
• Scala: @clasnake @shijinkui @ramzimaalej @chameleon82 @Bouillie @fish86
• Dart: @jaumard @josh-burton @amondnet @sbu-WBT @kuhnroyal @agilob @ahmednfwela
• F#: @nmfisher
• Crystal: @cyangle

---

Summary by cubic

Adds an opt-in global splitOperationsByContentType to split operations by request/response content-type when schemas differ. Defaults to off; typescript-fetch merges variants into one precisely typed method, and the sample/docs were refined to show all media types and case-insensitive matching.

• New Features

  • Global splitOperationsByContentType (default false), documented in global-properties.md; enable with --global-property splitOperationsByContentType=true.
  • Core: DefaultGenerator#processOperation delegates to the config to split; DefaultCodegen emits deduped request×response variants with collision-free ids and variant-index extensions.
  • typescript-fetch: merges variants into one method (request is a union discriminated by contentType; response typed via accept overloads). Adds ExclusiveUnion in runtime.mustache; extracts form params to apisFormParams.mustache and adds small partials to support the merge while keeping legacy output byte-identical when the option is off.
  • New sample and config: bin/configs/typescript-fetch-split-by-content-type.yaml and a typescript-fetch petstore sample with the option on; included in CI typecheck to catch regressions. Tests cover enums, forms, optional/no-body responses, and name collisions.
  • Docs/sample: merged-method docs now list the full request/response media-type union; sample switches XML to application/merge-patch+json; docs clarify this option chooses which media types get operations and does not add new encoders.

• Bug Fixes

  • typescript-fetch: compare response Content-Type case-insensitively to pick the right deserializer.
  • Petstore resttemplate-springBoot4-jackson3 sample: set spring-web to 7.0.5 to fix build.

^{Written for commit eec586e. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 138 files

<sub>Note: This PR contains a large number of files. cubic only reviews up to 100 files per PR, so some files may not have been reviewed. cubic prioritizes the most important files to review.
On a pro plan you can use ultrareview for larger PRs.

Re-trigger cubic</sub>

[AntoineDuComptoirDesPharmacies]

Hello @wing328,

I know you express your good feeling about dividing operations to manage this use case. (See : #19473)

Do not hesisaste to give me your point of view about this big change (opt-in) that would solve the problem for multiple langages.

Yours faithfully,
LCDP

[wing328]

please PM me via Slack to further discuss this to move this PR forward when you've time.

https://join.slack.com/t/openapi-generator/shared_invite/zt-36ucx4ybl-jYrN6euoYn6zxXNZdldoZA

[cubic-dev-ai]

All reported issues were addressed across 30 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

1 issue found across 20 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptFetchClientCodegen.java">
<violation number="1" location="modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptFetchClientCodegen.java:1093">
P3: Generated API documentation can list response media types in a different order from the OpenAPI response declaration when another response status has content: each narrowed variant carries all response-status media types, so `mediaTypesOf` interleaves them as it walks variants. Preserving the pre-split response media-type order would avoid this documentation regression.</violation>
</file>

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

P3: Generated API documentation can list response media types in a different order from the OpenAPI response declaration when another response status has content: each narrowed variant carries all response-status media types, so mediaTypesOf interleaves them as it walks variants. Preserving the pre-split response media-type order would avoid this documentation regression.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptFetchClientCodegen.java, line 1093:
<comment>Generated API documentation can list response media types in a different order from the OpenAPI response declaration when another response status has content: each narrowed variant carries all response-status media types, so `mediaTypesOf` interleaves them as it walks variants. Preserving the pre-split response media-type order would avoid this documentation regression.</comment>
<file context>
@@ -1084,13 +1085,39 @@ private void mergeContentTypeVariants(OperationsMap operations) {
+ // request axis was not split - a case where this union is the single value anyway - and never
+ // reads produces, so this is documentation only.
+ base.consumes = mediaTypesOf(requestVariants, v -> v.consumes);
+ base.produces = mediaTypesOf(responseVariants, v -> v.produces);
+
variants.stream().filter(op -> op != base).forEach(superseded::add);
</file context>

[AntoineDuComptoirDesPharmacies]

It's only mixing the order of generation, only esthetic, i propose not to fix this.

[wing328]

ran some tests locally and the results are good

let's give it a try

thanks for your contribution.

[jschonenberg]

@AntoineDuComptoirDesPharmacies thank you for your work!

Since splitOperationsByContentType was added as a global property, I would assume that it would automatically be available for all generators.
However, we are using the java generator and the property does not seem to be effective.

Is this as expected? Is it due to how the java generator is implemented?

[AntoineDuComptoirDesPharmacies]

This PR adds an opt-in splitOperationsByContentType option that fixes#6708: an operation may expose several request and/or response content-types with different schemas, but generators currently keep only the first one ("Multiple schemas found in the OAS 'content' section, returning only the first").
The result is a single, mistyped method, and the other content-types are unreachable.

The same underlying problem has been reported and worked around in a language-specific way in several places — e.g. #22095 (rust-axum), #8431 (Ruby), #13426 (TypeScript/Angular) and #10973 (Python request bodies). This PR addresses it generically in the core instead of per-generator.

The implementation is inspired by #19473, where operations were divided by content-type. The key difference here: the division is gated behind an opt-in option (splitOperationsByContentType, default false), so all existing generator outputs are unchanged and no current codegen is broken.

Why it is off by default

Some dynamically- or structurally-typed languages can already represent several input/return types within a single operationId, so splitting would be unnecessary (or even undesirable) for them:

• Python deserializes the response body from the actual Content-Type at runtime and returns a dynamically-typed object (see Adds request body content data to allow multiple content types to be sent to servers #10973 / Adds python-experimental which uses dynamic base classes #8325).
• Ruby maps the status / content-type to the return type at runtime in a single method ([Ruby] Incorrect return types if multiple responses are defined (reopened) #8431).
• TypeScript expresses it as a union return type, e.g. TypeA | TypeB, in a single method signature ([TS][Angular] better handling of multiple responses #13426).

Statically-typed / compiled languages (Java, C#, Go, Kotlin, Swift, ...) cannot overload a method by return type, so they benefit from one typed method per content-type — which is exactly what this option produces when enabled. Keeping it opt-in lets each consumer decide, without changing any default
output.

How it works

When the option is enabled, DefaultCodegen#preprocessOpenAPI divides an eligible operation into the cartesian product of its request-body and success-response content-types (deduplicated by schema). Each variant is a narrowed OpenAPI Operation (a single content-type on each axis) with a typed,
collision-free operationId — request appends With<Subtype> and response appends As<Subtype> (e.g. createReportWithXmlAsPdf). The variants are stored on the original operation under the x-content-type-variants extension and expanded by DefaultGenerator#processOperation, so each one re-enters
fromOperation and is typed natively by the target generator. The feature is therefore language-neutral: no per-language type re-derivation and no template changes.

Tests

Added unit tests in DefaultCodegenTest: the request×response cartesian (4 variants), the response-only case (2 variants), and a check that unambiguous operations are left untouched.

PR checklist

• [ X ] Read the contribution guidelines.
• [ X ] 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.
• [ X ] If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

Technical committee mention

This feature is opt-in and primarily benefits statically-typed / compiled generators, which cannot overload a method by return type and therefore gain one typed method per content-type. cc the relevant technical committee members:

• Java: @bbdouglas@sreeshas@jfiala@lukoyanov@cbornet@jeff9finger@karismann@Zomzog@lwlee2608@martin-mfg
• Java Spring: @cachescrubber@welshm@MelleD@atextor@manedev79@javisst@borsch @banlevente
• Kotlin: @andrewemery@4brunu @yutaka0m @stefankoppier@e5l@dennisameling
• C#: @mandrean@shibayan@Blackclaws@lucamazzanti@iBicha
• Go: @antihax@grokify@kemokemo@jirikuncar@ph4r5h4d@lwj5
• Rust: @frol@farcaller@richardwhiuk@paladinzh@jacob-pro@dsteeley
• Swift: @jgavris@ehyche@Edubits@jaz-ah@dydus0x14
• C++: @ravinikam@stkrwork@etherealjoy@MartinDelille @muttleyxd @aminya
• C: @zhemant @ityuhui @michelealbano @eafer
• Scala: @clasnake @shijinkui @ramzimaalej @chameleon82 @Bouillie @fish86
• Dart: @jaumard @josh-burton @amondnet @sbu-WBT @kuhnroyal @agilob @ahmednfwela
• F#: @nmfisher
• Crystal: @cyangle

---

Summary by cubic

Adds an opt-in global splitOperationsByContentType to split operations by request/response content-type when schemas differ. Defaults to off; typescript-fetch merges variants into one precisely typed method, and the sample/docs were refined to show all media types and case-insensitive matching.

• New Features

  • Global splitOperationsByContentType (default false), documented in global-properties.md; enable with --global-property splitOperationsByContentType=true.
  • Core: DefaultGenerator#processOperation delegates to the config to split; DefaultCodegen emits deduped request×response variants with collision-free ids and variant-index extensions.
  • typescript-fetch: merges variants into one method (request is a union discriminated by contentType; response typed via accept overloads). Adds ExclusiveUnion in runtime.mustache; extracts form params to apisFormParams.mustache and adds small partials to support the merge while keeping legacy output byte-identical when the option is off.
  • New sample and config: bin/configs/typescript-fetch-split-by-content-type.yaml and a typescript-fetch petstore sample with the option on; included in CI typecheck to catch regressions. Tests cover enums, forms, optional/no-body responses, and name collisions.
  • Docs/sample: merged-method docs now list the full request/response media-type union; sample switches XML to application/merge-patch+json; docs clarify this option chooses which media types get operations and does not add new encoders.

• Bug Fixes

  • typescript-fetch: compare response Content-Type case-insensitively to pick the right deserializer.
  • Petstore resttemplate-springBoot4-jackson3 sample: set spring-web to 7.0.5 to fix build.

^{Written for commit eec586e. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 138 files

<sub>Note: This PR contains a large number of files. cubic only reviews up to 100 files per PR, so some files may not have been reviewed. cubic prioritizes the most important files to review.
On a pro plan you can use ultrareview for larger PRs.

Re-trigger cubic</sub>

[AntoineDuComptoirDesPharmacies]

Hello @wing328,

I know you express your good feeling about dividing operations to manage this use case. (See : #19473)

Do not hesisaste to give me your point of view about this big change (opt-in) that would solve the problem for multiple langages.

Yours faithfully,
LCDP

[wing328]

please PM me via Slack to further discuss this to move this PR forward when you've time.

https://join.slack.com/t/openapi-generator/shared_invite/zt-36ucx4ybl-jYrN6euoYn6zxXNZdldoZA

[cubic-dev-ai]

All reported issues were addressed across 30 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

1 issue found across 20 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptFetchClientCodegen.java">
<violation number="1" location="modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptFetchClientCodegen.java:1093">
P3: Generated API documentation can list response media types in a different order from the OpenAPI response declaration when another response status has content: each narrowed variant carries all response-status media types, so `mediaTypesOf` interleaves them as it walks variants. Preserving the pre-split response media-type order would avoid this documentation regression.</violation>
</file>

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

P3: Generated API documentation can list response media types in a different order from the OpenAPI response declaration when another response status has content: each narrowed variant carries all response-status media types, so mediaTypesOf interleaves them as it walks variants. Preserving the pre-split response media-type order would avoid this documentation regression.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptFetchClientCodegen.java, line 1093:
<comment>Generated API documentation can list response media types in a different order from the OpenAPI response declaration when another response status has content: each narrowed variant carries all response-status media types, so `mediaTypesOf` interleaves them as it walks variants. Preserving the pre-split response media-type order would avoid this documentation regression.</comment>
<file context>
@@ -1084,13 +1085,39 @@ private void mergeContentTypeVariants(OperationsMap operations) {
+ // request axis was not split - a case where this union is the single value anyway - and never
+ // reads produces, so this is documentation only.
+ base.consumes = mediaTypesOf(requestVariants, v -> v.consumes);
+ base.produces = mediaTypesOf(responseVariants, v -> v.produces);
+
variants.stream().filter(op -> op != base).forEach(superseded::add);
</file context>

[AntoineDuComptoirDesPharmacies]

It's only mixing the order of generation, only esthetic, i propose not to fix this.

[wing328]

ran some tests locally and the results are good

let's give it a try

thanks for your contribution.

[jschonenberg]

@AntoineDuComptoirDesPharmacies thank you for your work!

Since splitOperationsByContentType was added as a global property, I would assume that it would automatically be available for all generators.
However, we are using the java generator and the property does not seem to be effective.

Is this as expected? Is it due to how the java generator is implemented?

[AntoineDuComptoirDesPharmacies]

This PR adds an opt-in splitOperationsByContentType option that fixes#6708: an operation may expose several request and/or response content-types with different schemas, but generators currently keep only the first one ("Multiple schemas found in the OAS 'content' section, returning only the first").
The result is a single, mistyped method, and the other content-types are unreachable.

The same underlying problem has been reported and worked around in a language-specific way in several places — e.g. #22095 (rust-axum), #8431 (Ruby), #13426 (TypeScript/Angular) and #10973 (Python request bodies). This PR addresses it generically in the core instead of per-generator.

The implementation is inspired by #19473, where operations were divided by content-type. The key difference here: the division is gated behind an opt-in option (splitOperationsByContentType, default false), so all existing generator outputs are unchanged and no current codegen is broken.

Why it is off by default

Some dynamically- or structurally-typed languages can already represent several input/return types within a single operationId, so splitting would be unnecessary (or even undesirable) for them:

• Python deserializes the response body from the actual Content-Type at runtime and returns a dynamically-typed object (see Adds request body content data to allow multiple content types to be sent to servers #10973 / Adds python-experimental which uses dynamic base classes #8325).
• Ruby maps the status / content-type to the return type at runtime in a single method ([Ruby] Incorrect return types if multiple responses are defined (reopened) #8431).
• TypeScript expresses it as a union return type, e.g. TypeA | TypeB, in a single method signature ([TS][Angular] better handling of multiple responses #13426).

Statically-typed / compiled languages (Java, C#, Go, Kotlin, Swift, ...) cannot overload a method by return type, so they benefit from one typed method per content-type — which is exactly what this option produces when enabled. Keeping it opt-in lets each consumer decide, without changing any default
output.

How it works

When the option is enabled, DefaultCodegen#preprocessOpenAPI divides an eligible operation into the cartesian product of its request-body and success-response content-types (deduplicated by schema). Each variant is a narrowed OpenAPI Operation (a single content-type on each axis) with a typed,
collision-free operationId — request appends With<Subtype> and response appends As<Subtype> (e.g. createReportWithXmlAsPdf). The variants are stored on the original operation under the x-content-type-variants extension and expanded by DefaultGenerator#processOperation, so each one re-enters
fromOperation and is typed natively by the target generator. The feature is therefore language-neutral: no per-language type re-derivation and no template changes.

Tests

Added unit tests in DefaultCodegenTest: the request×response cartesian (4 variants), the response-only case (2 variants), and a check that unambiguous operations are left untouched.

PR checklist

• [ X ] Read the contribution guidelines.
• [ X ] 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.
• [ X ] If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

Technical committee mention

This feature is opt-in and primarily benefits statically-typed / compiled generators, which cannot overload a method by return type and therefore gain one typed method per content-type. cc the relevant technical committee members:

• Java: @bbdouglas@sreeshas@jfiala@lukoyanov@cbornet@jeff9finger@karismann@Zomzog@lwlee2608@martin-mfg
• Java Spring: @cachescrubber@welshm@MelleD@atextor@manedev79@javisst@borsch @banlevente
• Kotlin: @andrewemery@4brunu @yutaka0m @stefankoppier@e5l@dennisameling
• C#: @mandrean@shibayan@Blackclaws@lucamazzanti@iBicha
• Go: @antihax@grokify@kemokemo@jirikuncar@ph4r5h4d@lwj5
• Rust: @frol@farcaller@richardwhiuk@paladinzh@jacob-pro@dsteeley
• Swift: @jgavris@ehyche@Edubits@jaz-ah@dydus0x14
• C++: @ravinikam@stkrwork@etherealjoy@MartinDelille @muttleyxd @aminya
• C: @zhemant @ityuhui @michelealbano @eafer
• Scala: @clasnake @shijinkui @ramzimaalej @chameleon82 @Bouillie @fish86
• Dart: @jaumard @josh-burton @amondnet @sbu-WBT @kuhnroyal @agilob @ahmednfwela
• F#: @nmfisher
• Crystal: @cyangle

---

Summary by cubic

Adds an opt-in global splitOperationsByContentType to split operations by request/response content-type when schemas differ. Defaults to off; typescript-fetch merges variants into one precisely typed method, and the sample/docs were refined to show all media types and case-insensitive matching.

• New Features

  • Global splitOperationsByContentType (default false), documented in global-properties.md; enable with --global-property splitOperationsByContentType=true.
  • Core: DefaultGenerator#processOperation delegates to the config to split; DefaultCodegen emits deduped request×response variants with collision-free ids and variant-index extensions.
  • typescript-fetch: merges variants into one method (request is a union discriminated by contentType; response typed via accept overloads). Adds ExclusiveUnion in runtime.mustache; extracts form params to apisFormParams.mustache and adds small partials to support the merge while keeping legacy output byte-identical when the option is off.
  • New sample and config: bin/configs/typescript-fetch-split-by-content-type.yaml and a typescript-fetch petstore sample with the option on; included in CI typecheck to catch regressions. Tests cover enums, forms, optional/no-body responses, and name collisions.
  • Docs/sample: merged-method docs now list the full request/response media-type union; sample switches XML to application/merge-patch+json; docs clarify this option chooses which media types get operations and does not add new encoders.

• Bug Fixes

  • typescript-fetch: compare response Content-Type case-insensitively to pick the right deserializer.
  • Petstore resttemplate-springBoot4-jackson3 sample: set spring-web to 7.0.5 to fix build.

^{Written for commit eec586e. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 138 files

<sub>Note: This PR contains a large number of files. cubic only reviews up to 100 files per PR, so some files may not have been reviewed. cubic prioritizes the most important files to review.
On a pro plan you can use ultrareview for larger PRs.

Re-trigger cubic</sub>

[AntoineDuComptoirDesPharmacies]

Hello @wing328,

I know you express your good feeling about dividing operations to manage this use case. (See : #19473)

Do not hesisaste to give me your point of view about this big change (opt-in) that would solve the problem for multiple langages.

Yours faithfully,
LCDP

[wing328]

please PM me via Slack to further discuss this to move this PR forward when you've time.

https://join.slack.com/t/openapi-generator/shared_invite/zt-36ucx4ybl-jYrN6euoYn6zxXNZdldoZA

[cubic-dev-ai]

All reported issues were addressed across 30 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

1 issue found across 20 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptFetchClientCodegen.java">
<violation number="1" location="modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptFetchClientCodegen.java:1093">
P3: Generated API documentation can list response media types in a different order from the OpenAPI response declaration when another response status has content: each narrowed variant carries all response-status media types, so `mediaTypesOf` interleaves them as it walks variants. Preserving the pre-split response media-type order would avoid this documentation regression.</violation>
</file>

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

P3: Generated API documentation can list response media types in a different order from the OpenAPI response declaration when another response status has content: each narrowed variant carries all response-status media types, so mediaTypesOf interleaves them as it walks variants. Preserving the pre-split response media-type order would avoid this documentation regression.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptFetchClientCodegen.java, line 1093:
<comment>Generated API documentation can list response media types in a different order from the OpenAPI response declaration when another response status has content: each narrowed variant carries all response-status media types, so `mediaTypesOf` interleaves them as it walks variants. Preserving the pre-split response media-type order would avoid this documentation regression.</comment>
<file context>
@@ -1084,13 +1085,39 @@ private void mergeContentTypeVariants(OperationsMap operations) {
+ // request axis was not split - a case where this union is the single value anyway - and never
+ // reads produces, so this is documentation only.
+ base.consumes = mediaTypesOf(requestVariants, v -> v.consumes);
+ base.produces = mediaTypesOf(responseVariants, v -> v.produces);
+
variants.stream().filter(op -> op != base).forEach(superseded::add);
</file context>

[AntoineDuComptoirDesPharmacies]

It's only mixing the order of generation, only esthetic, i propose not to fix this.

[wing328]

ran some tests locally and the results are good

let's give it a try

thanks for your contribution.

[jschonenberg]

@AntoineDuComptoirDesPharmacies thank you for your work!

Since splitOperationsByContentType was added as a global property, I would assume that it would automatically be available for all generators.
However, we are using the java generator and the property does not seem to be effective.

Is this as expected? Is it due to how the java generator is implemented?

[AntoineDuComptoirDesPharmacies]

This PR adds an opt-in splitOperationsByContentType option that fixes#6708: an operation may expose several request and/or response content-types with different schemas, but generators currently keep only the first one ("Multiple schemas found in the OAS 'content' section, returning only the first").
The result is a single, mistyped method, and the other content-types are unreachable.

The same underlying problem has been reported and worked around in a language-specific way in several places — e.g. #22095 (rust-axum), #8431 (Ruby), #13426 (TypeScript/Angular) and #10973 (Python request bodies). This PR addresses it generically in the core instead of per-generator.

The implementation is inspired by #19473, where operations were divided by content-type. The key difference here: the division is gated behind an opt-in option (splitOperationsByContentType, default false), so all existing generator outputs are unchanged and no current codegen is broken.

Why it is off by default

Some dynamically- or structurally-typed languages can already represent several input/return types within a single operationId, so splitting would be unnecessary (or even undesirable) for them:

• Python deserializes the response body from the actual Content-Type at runtime and returns a dynamically-typed object (see Adds request body content data to allow multiple content types to be sent to servers #10973 / Adds python-experimental which uses dynamic base classes #8325).
• Ruby maps the status / content-type to the return type at runtime in a single method ([Ruby] Incorrect return types if multiple responses are defined (reopened) #8431).
• TypeScript expresses it as a union return type, e.g. TypeA | TypeB, in a single method signature ([TS][Angular] better handling of multiple responses #13426).

Statically-typed / compiled languages (Java, C#, Go, Kotlin, Swift, ...) cannot overload a method by return type, so they benefit from one typed method per content-type — which is exactly what this option produces when enabled. Keeping it opt-in lets each consumer decide, without changing any default
output.

How it works

When the option is enabled, DefaultCodegen#preprocessOpenAPI divides an eligible operation into the cartesian product of its request-body and success-response content-types (deduplicated by schema). Each variant is a narrowed OpenAPI Operation (a single content-type on each axis) with a typed,
collision-free operationId — request appends With<Subtype> and response appends As<Subtype> (e.g. createReportWithXmlAsPdf). The variants are stored on the original operation under the x-content-type-variants extension and expanded by DefaultGenerator#processOperation, so each one re-enters
fromOperation and is typed natively by the target generator. The feature is therefore language-neutral: no per-language type re-derivation and no template changes.

Tests

Added unit tests in DefaultCodegenTest: the request×response cartesian (4 variants), the response-only case (2 variants), and a check that unambiguous operations are left untouched.

PR checklist

• [ X ] Read the contribution guidelines.
• [ X ] 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.
• [ X ] If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

Technical committee mention

This feature is opt-in and primarily benefits statically-typed / compiled generators, which cannot overload a method by return type and therefore gain one typed method per content-type. cc the relevant technical committee members:

• Java: @bbdouglas@sreeshas@jfiala@lukoyanov@cbornet@jeff9finger@karismann@Zomzog@lwlee2608@martin-mfg
• Java Spring: @cachescrubber@welshm@MelleD@atextor@manedev79@javisst@borsch @banlevente
• Kotlin: @andrewemery@4brunu @yutaka0m @stefankoppier@e5l@dennisameling
• C#: @mandrean@shibayan@Blackclaws@lucamazzanti@iBicha
• Go: @antihax@grokify@kemokemo@jirikuncar@ph4r5h4d@lwj5
• Rust: @frol@farcaller@richardwhiuk@paladinzh@jacob-pro@dsteeley
• Swift: @jgavris@ehyche@Edubits@jaz-ah@dydus0x14
• C++: @ravinikam@stkrwork@etherealjoy@MartinDelille @muttleyxd @aminya
• C: @zhemant @ityuhui @michelealbano @eafer
• Scala: @clasnake @shijinkui @ramzimaalej @chameleon82 @Bouillie @fish86
• Dart: @jaumard @josh-burton @amondnet @sbu-WBT @kuhnroyal @agilob @ahmednfwela
• F#: @nmfisher
• Crystal: @cyangle

---

Summary by cubic

Adds an opt-in global splitOperationsByContentType to split operations by request/response content-type when schemas differ. Defaults to off; typescript-fetch merges variants into one precisely typed method, and the sample/docs were refined to show all media types and case-insensitive matching.

• New Features

  • Global splitOperationsByContentType (default false), documented in global-properties.md; enable with --global-property splitOperationsByContentType=true.
  • Core: DefaultGenerator#processOperation delegates to the config to split; DefaultCodegen emits deduped request×response variants with collision-free ids and variant-index extensions.
  • typescript-fetch: merges variants into one method (request is a union discriminated by contentType; response typed via accept overloads). Adds ExclusiveUnion in runtime.mustache; extracts form params to apisFormParams.mustache and adds small partials to support the merge while keeping legacy output byte-identical when the option is off.
  • New sample and config: bin/configs/typescript-fetch-split-by-content-type.yaml and a typescript-fetch petstore sample with the option on; included in CI typecheck to catch regressions. Tests cover enums, forms, optional/no-body responses, and name collisions.
  • Docs/sample: merged-method docs now list the full request/response media-type union; sample switches XML to application/merge-patch+json; docs clarify this option chooses which media types get operations and does not add new encoders.

• Bug Fixes

  • typescript-fetch: compare response Content-Type case-insensitively to pick the right deserializer.
  • Petstore resttemplate-springBoot4-jackson3 sample: set spring-web to 7.0.5 to fix build.

^{Written for commit eec586e. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 138 files

<sub>Note: This PR contains a large number of files. cubic only reviews up to 100 files per PR, so some files may not have been reviewed. cubic prioritizes the most important files to review.
On a pro plan you can use ultrareview for larger PRs.

Re-trigger cubic</sub>

[AntoineDuComptoirDesPharmacies]

Hello @wing328,

I know you express your good feeling about dividing operations to manage this use case. (See : #19473)

Do not hesisaste to give me your point of view about this big change (opt-in) that would solve the problem for multiple langages.

Yours faithfully,
LCDP

[wing328]

please PM me via Slack to further discuss this to move this PR forward when you've time.

https://join.slack.com/t/openapi-generator/shared_invite/zt-36ucx4ybl-jYrN6euoYn6zxXNZdldoZA

[cubic-dev-ai]

All reported issues were addressed across 30 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

1 issue found across 20 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptFetchClientCodegen.java">
<violation number="1" location="modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptFetchClientCodegen.java:1093">
P3: Generated API documentation can list response media types in a different order from the OpenAPI response declaration when another response status has content: each narrowed variant carries all response-status media types, so `mediaTypesOf` interleaves them as it walks variants. Preserving the pre-split response media-type order would avoid this documentation regression.</violation>
</file>

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

P3: Generated API documentation can list response media types in a different order from the OpenAPI response declaration when another response status has content: each narrowed variant carries all response-status media types, so mediaTypesOf interleaves them as it walks variants. Preserving the pre-split response media-type order would avoid this documentation regression.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptFetchClientCodegen.java, line 1093:
<comment>Generated API documentation can list response media types in a different order from the OpenAPI response declaration when another response status has content: each narrowed variant carries all response-status media types, so `mediaTypesOf` interleaves them as it walks variants. Preserving the pre-split response media-type order would avoid this documentation regression.</comment>
<file context>
@@ -1084,13 +1085,39 @@ private void mergeContentTypeVariants(OperationsMap operations) {
+ // request axis was not split - a case where this union is the single value anyway - and never
+ // reads produces, so this is documentation only.
+ base.consumes = mediaTypesOf(requestVariants, v -> v.consumes);
+ base.produces = mediaTypesOf(responseVariants, v -> v.produces);
+
variants.stream().filter(op -> op != base).forEach(superseded::add);
</file context>

[AntoineDuComptoirDesPharmacies]

It's only mixing the order of generation, only esthetic, i propose not to fix this.

[wing328]

ran some tests locally and the results are good

let's give it a try

thanks for your contribution.

[jschonenberg]

@AntoineDuComptoirDesPharmacies thank you for your work!

Since splitOperationsByContentType was added as a global property, I would assume that it would automatically be available for all generators.
However, we are using the java generator and the property does not seem to be effective.

Is this as expected? Is it due to how the java generator is implemented?

[AntoineDuComptoirDesPharmacies]

This PR adds an opt-in splitOperationsByContentType option that fixes#6708: an operation may expose several request and/or response content-types with different schemas, but generators currently keep only the first one ("Multiple schemas found in the OAS 'content' section, returning only the first").
The result is a single, mistyped method, and the other content-types are unreachable.

The same underlying problem has been reported and worked around in a language-specific way in several places — e.g. #22095 (rust-axum), #8431 (Ruby), #13426 (TypeScript/Angular) and #10973 (Python request bodies). This PR addresses it generically in the core instead of per-generator.

The implementation is inspired by #19473, where operations were divided by content-type. The key difference here: the division is gated behind an opt-in option (splitOperationsByContentType, default false), so all existing generator outputs are unchanged and no current codegen is broken.

Why it is off by default

Some dynamically- or structurally-typed languages can already represent several input/return types within a single operationId, so splitting would be unnecessary (or even undesirable) for them:

• Python deserializes the response body from the actual Content-Type at runtime and returns a dynamically-typed object (see Adds request body content data to allow multiple content types to be sent to servers #10973 / Adds python-experimental which uses dynamic base classes #8325).
• Ruby maps the status / content-type to the return type at runtime in a single method ([Ruby] Incorrect return types if multiple responses are defined (reopened) #8431).
• TypeScript expresses it as a union return type, e.g. TypeA | TypeB, in a single method signature ([TS][Angular] better handling of multiple responses #13426).

Statically-typed / compiled languages (Java, C#, Go, Kotlin, Swift, ...) cannot overload a method by return type, so they benefit from one typed method per content-type — which is exactly what this option produces when enabled. Keeping it opt-in lets each consumer decide, without changing any default
output.

How it works

When the option is enabled, DefaultCodegen#preprocessOpenAPI divides an eligible operation into the cartesian product of its request-body and success-response content-types (deduplicated by schema). Each variant is a narrowed OpenAPI Operation (a single content-type on each axis) with a typed,
collision-free operationId — request appends With<Subtype> and response appends As<Subtype> (e.g. createReportWithXmlAsPdf). The variants are stored on the original operation under the x-content-type-variants extension and expanded by DefaultGenerator#processOperation, so each one re-enters
fromOperation and is typed natively by the target generator. The feature is therefore language-neutral: no per-language type re-derivation and no template changes.

Tests

Added unit tests in DefaultCodegenTest: the request×response cartesian (4 variants), the response-only case (2 variants), and a check that unambiguous operations are left untouched.

PR checklist

• [ X ] Read the contribution guidelines.
• [ X ] 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.
• [ X ] If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

Technical committee mention

This feature is opt-in and primarily benefits statically-typed / compiled generators, which cannot overload a method by return type and therefore gain one typed method per content-type. cc the relevant technical committee members:

• Java: @bbdouglas@sreeshas@jfiala@lukoyanov@cbornet@jeff9finger@karismann@Zomzog@lwlee2608@martin-mfg
• Java Spring: @cachescrubber@welshm@MelleD@atextor@manedev79@javisst@borsch @banlevente
• Kotlin: @andrewemery@4brunu @yutaka0m @stefankoppier@e5l@dennisameling
• C#: @mandrean@shibayan@Blackclaws@lucamazzanti@iBicha
• Go: @antihax@grokify@kemokemo@jirikuncar@ph4r5h4d@lwj5
• Rust: @frol@farcaller@richardwhiuk@paladinzh@jacob-pro@dsteeley
• Swift: @jgavris@ehyche@Edubits@jaz-ah@dydus0x14
• C++: @ravinikam@stkrwork@etherealjoy@MartinDelille @muttleyxd @aminya
• C: @zhemant @ityuhui @michelealbano @eafer
• Scala: @clasnake @shijinkui @ramzimaalej @chameleon82 @Bouillie @fish86
• Dart: @jaumard @josh-burton @amondnet @sbu-WBT @kuhnroyal @agilob @ahmednfwela
• F#: @nmfisher
• Crystal: @cyangle

---

Summary by cubic

Adds an opt-in global splitOperationsByContentType to split operations by request/response content-type when schemas differ. Defaults to off; typescript-fetch merges variants into one precisely typed method, and the sample/docs were refined to show all media types and case-insensitive matching.

• New Features

  • Global splitOperationsByContentType (default false), documented in global-properties.md; enable with --global-property splitOperationsByContentType=true.
  • Core: DefaultGenerator#processOperation delegates to the config to split; DefaultCodegen emits deduped request×response variants with collision-free ids and variant-index extensions.
  • typescript-fetch: merges variants into one method (request is a union discriminated by contentType; response typed via accept overloads). Adds ExclusiveUnion in runtime.mustache; extracts form params to apisFormParams.mustache and adds small partials to support the merge while keeping legacy output byte-identical when the option is off.
  • New sample and config: bin/configs/typescript-fetch-split-by-content-type.yaml and a typescript-fetch petstore sample with the option on; included in CI typecheck to catch regressions. Tests cover enums, forms, optional/no-body responses, and name collisions.
  • Docs/sample: merged-method docs now list the full request/response media-type union; sample switches XML to application/merge-patch+json; docs clarify this option chooses which media types get operations and does not add new encoders.

• Bug Fixes

  • typescript-fetch: compare response Content-Type case-insensitively to pick the right deserializer.
  • Petstore resttemplate-springBoot4-jackson3 sample: set spring-web to 7.0.5 to fix build.

^{Written for commit eec586e. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 138 files

<sub>Note: This PR contains a large number of files. cubic only reviews up to 100 files per PR, so some files may not have been reviewed. cubic prioritizes the most important files to review.
On a pro plan you can use ultrareview for larger PRs.

Re-trigger cubic</sub>

[AntoineDuComptoirDesPharmacies]

Hello @wing328,

I know you express your good feeling about dividing operations to manage this use case. (See : #19473)

Do not hesisaste to give me your point of view about this big change (opt-in) that would solve the problem for multiple langages.

Yours faithfully,
LCDP

[wing328]

please PM me via Slack to further discuss this to move this PR forward when you've time.

https://join.slack.com/t/openapi-generator/shared_invite/zt-36ucx4ybl-jYrN6euoYn6zxXNZdldoZA

[cubic-dev-ai]

All reported issues were addressed across 30 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

1 issue found across 20 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptFetchClientCodegen.java">
<violation number="1" location="modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptFetchClientCodegen.java:1093">
P3: Generated API documentation can list response media types in a different order from the OpenAPI response declaration when another response status has content: each narrowed variant carries all response-status media types, so `mediaTypesOf` interleaves them as it walks variants. Preserving the pre-split response media-type order would avoid this documentation regression.</violation>
</file>

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

P3: Generated API documentation can list response media types in a different order from the OpenAPI response declaration when another response status has content: each narrowed variant carries all response-status media types, so mediaTypesOf interleaves them as it walks variants. Preserving the pre-split response media-type order would avoid this documentation regression.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptFetchClientCodegen.java, line 1093:
<comment>Generated API documentation can list response media types in a different order from the OpenAPI response declaration when another response status has content: each narrowed variant carries all response-status media types, so `mediaTypesOf` interleaves them as it walks variants. Preserving the pre-split response media-type order would avoid this documentation regression.</comment>
<file context>
@@ -1084,13 +1085,39 @@ private void mergeContentTypeVariants(OperationsMap operations) {
+ // request axis was not split - a case where this union is the single value anyway - and never
+ // reads produces, so this is documentation only.
+ base.consumes = mediaTypesOf(requestVariants, v -> v.consumes);
+ base.produces = mediaTypesOf(responseVariants, v -> v.produces);
+
variants.stream().filter(op -> op != base).forEach(superseded::add);
</file context>

[AntoineDuComptoirDesPharmacies]

It's only mixing the order of generation, only esthetic, i propose not to fix this.

[wing328]

ran some tests locally and the results are good

let's give it a try

thanks for your contribution.

[jschonenberg]

@AntoineDuComptoirDesPharmacies thank you for your work!

Since splitOperationsByContentType was added as a global property, I would assume that it would automatically be available for all generators.
However, we are using the java generator and the property does not seem to be effective.

Is this as expected? Is it due to how the java generator is implemented?

[AntoineDuComptoirDesPharmacies]

This PR adds an opt-in splitOperationsByContentType option that fixes#6708: an operation may expose several request and/or response content-types with different schemas, but generators currently keep only the first one ("Multiple schemas found in the OAS 'content' section, returning only the first").
The result is a single, mistyped method, and the other content-types are unreachable.

The same underlying problem has been reported and worked around in a language-specific way in several places — e.g. #22095 (rust-axum), #8431 (Ruby), #13426 (TypeScript/Angular) and #10973 (Python request bodies). This PR addresses it generically in the core instead of per-generator.

The implementation is inspired by #19473, where operations were divided by content-type. The key difference here: the division is gated behind an opt-in option (splitOperationsByContentType, default false), so all existing generator outputs are unchanged and no current codegen is broken.

Why it is off by default

Some dynamically- or structurally-typed languages can already represent several input/return types within a single operationId, so splitting would be unnecessary (or even undesirable) for them:

• Python deserializes the response body from the actual Content-Type at runtime and returns a dynamically-typed object (see Adds request body content data to allow multiple content types to be sent to servers #10973 / Adds python-experimental which uses dynamic base classes #8325).
• Ruby maps the status / content-type to the return type at runtime in a single method ([Ruby] Incorrect return types if multiple responses are defined (reopened) #8431).
• TypeScript expresses it as a union return type, e.g. TypeA | TypeB, in a single method signature ([TS][Angular] better handling of multiple responses #13426).

Statically-typed / compiled languages (Java, C#, Go, Kotlin, Swift, ...) cannot overload a method by return type, so they benefit from one typed method per content-type — which is exactly what this option produces when enabled. Keeping it opt-in lets each consumer decide, without changing any default
output.

How it works

When the option is enabled, DefaultCodegen#preprocessOpenAPI divides an eligible operation into the cartesian product of its request-body and success-response content-types (deduplicated by schema). Each variant is a narrowed OpenAPI Operation (a single content-type on each axis) with a typed,
collision-free operationId — request appends With<Subtype> and response appends As<Subtype> (e.g. createReportWithXmlAsPdf). The variants are stored on the original operation under the x-content-type-variants extension and expanded by DefaultGenerator#processOperation, so each one re-enters
fromOperation and is typed natively by the target generator. The feature is therefore language-neutral: no per-language type re-derivation and no template changes.

Tests

Added unit tests in DefaultCodegenTest: the request×response cartesian (4 variants), the response-only case (2 variants), and a check that unambiguous operations are left untouched.

PR checklist

• [ X ] Read the contribution guidelines.
• [ X ] 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.
• [ X ] If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

Technical committee mention

This feature is opt-in and primarily benefits statically-typed / compiled generators, which cannot overload a method by return type and therefore gain one typed method per content-type. cc the relevant technical committee members:

• Java: @bbdouglas@sreeshas@jfiala@lukoyanov@cbornet@jeff9finger@karismann@Zomzog@lwlee2608@martin-mfg
• Java Spring: @cachescrubber@welshm@MelleD@atextor@manedev79@javisst@borsch @banlevente
• Kotlin: @andrewemery@4brunu @yutaka0m @stefankoppier@e5l@dennisameling
• C#: @mandrean@shibayan@Blackclaws@lucamazzanti@iBicha
• Go: @antihax@grokify@kemokemo@jirikuncar@ph4r5h4d@lwj5
• Rust: @frol@farcaller@richardwhiuk@paladinzh@jacob-pro@dsteeley
• Swift: @jgavris@ehyche@Edubits@jaz-ah@dydus0x14
• C++: @ravinikam@stkrwork@etherealjoy@MartinDelille @muttleyxd @aminya
• C: @zhemant @ityuhui @michelealbano @eafer
• Scala: @clasnake @shijinkui @ramzimaalej @chameleon82 @Bouillie @fish86
• Dart: @jaumard @josh-burton @amondnet @sbu-WBT @kuhnroyal @agilob @ahmednfwela
• F#: @nmfisher
• Crystal: @cyangle

---

Summary by cubic

Adds an opt-in global splitOperationsByContentType to split operations by request/response content-type when schemas differ. Defaults to off; typescript-fetch merges variants into one precisely typed method, and the sample/docs were refined to show all media types and case-insensitive matching.

• New Features

  • Global splitOperationsByContentType (default false), documented in global-properties.md; enable with --global-property splitOperationsByContentType=true.
  • Core: DefaultGenerator#processOperation delegates to the config to split; DefaultCodegen emits deduped request×response variants with collision-free ids and variant-index extensions.
  • typescript-fetch: merges variants into one method (request is a union discriminated by contentType; response typed via accept overloads). Adds ExclusiveUnion in runtime.mustache; extracts form params to apisFormParams.mustache and adds small partials to support the merge while keeping legacy output byte-identical when the option is off.
  • New sample and config: bin/configs/typescript-fetch-split-by-content-type.yaml and a typescript-fetch petstore sample with the option on; included in CI typecheck to catch regressions. Tests cover enums, forms, optional/no-body responses, and name collisions.
  • Docs/sample: merged-method docs now list the full request/response media-type union; sample switches XML to application/merge-patch+json; docs clarify this option chooses which media types get operations and does not add new encoders.

• Bug Fixes

  • typescript-fetch: compare response Content-Type case-insensitively to pick the right deserializer.
  • Petstore resttemplate-springBoot4-jackson3 sample: set spring-web to 7.0.5 to fix build.

^{Written for commit eec586e. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 138 files

<sub>Note: This PR contains a large number of files. cubic only reviews up to 100 files per PR, so some files may not have been reviewed. cubic prioritizes the most important files to review.
On a pro plan you can use ultrareview for larger PRs.

Re-trigger cubic</sub>

[AntoineDuComptoirDesPharmacies]

Hello @wing328,

I know you express your good feeling about dividing operations to manage this use case. (See : #19473)

Do not hesisaste to give me your point of view about this big change (opt-in) that would solve the problem for multiple langages.

Yours faithfully,
LCDP

[wing328]

please PM me via Slack to further discuss this to move this PR forward when you've time.

https://join.slack.com/t/openapi-generator/shared_invite/zt-36ucx4ybl-jYrN6euoYn6zxXNZdldoZA

[cubic-dev-ai]

All reported issues were addressed across 30 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

1 issue found across 20 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptFetchClientCodegen.java">
<violation number="1" location="modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptFetchClientCodegen.java:1093">
P3: Generated API documentation can list response media types in a different order from the OpenAPI response declaration when another response status has content: each narrowed variant carries all response-status media types, so `mediaTypesOf` interleaves them as it walks variants. Preserving the pre-split response media-type order would avoid this documentation regression.</violation>
</file>

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

P3: Generated API documentation can list response media types in a different order from the OpenAPI response declaration when another response status has content: each narrowed variant carries all response-status media types, so mediaTypesOf interleaves them as it walks variants. Preserving the pre-split response media-type order would avoid this documentation regression.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptFetchClientCodegen.java, line 1093:
<comment>Generated API documentation can list response media types in a different order from the OpenAPI response declaration when another response status has content: each narrowed variant carries all response-status media types, so `mediaTypesOf` interleaves them as it walks variants. Preserving the pre-split response media-type order would avoid this documentation regression.</comment>
<file context>
@@ -1084,13 +1085,39 @@ private void mergeContentTypeVariants(OperationsMap operations) {
+ // request axis was not split - a case where this union is the single value anyway - and never
+ // reads produces, so this is documentation only.
+ base.consumes = mediaTypesOf(requestVariants, v -> v.consumes);
+ base.produces = mediaTypesOf(responseVariants, v -> v.produces);
+
variants.stream().filter(op -> op != base).forEach(superseded::add);
</file context>

[AntoineDuComptoirDesPharmacies]

It's only mixing the order of generation, only esthetic, i propose not to fix this.

[wing328]

ran some tests locally and the results are good

let's give it a try

thanks for your contribution.

[jschonenberg]

@AntoineDuComptoirDesPharmacies thank you for your work!

Since splitOperationsByContentType was added as a global property, I would assume that it would automatically be available for all generators.
However, we are using the java generator and the property does not seem to be effective.

Is this as expected? Is it due to how the java generator is implemented?

[AntoineDuComptoirDesPharmacies]

This PR adds an opt-in splitOperationsByContentType option that fixes#6708: an operation may expose several request and/or response content-types with different schemas, but generators currently keep only the first one ("Multiple schemas found in the OAS 'content' section, returning only the first").
The result is a single, mistyped method, and the other content-types are unreachable.

The same underlying problem has been reported and worked around in a language-specific way in several places — e.g. #22095 (rust-axum), #8431 (Ruby), #13426 (TypeScript/Angular) and #10973 (Python request bodies). This PR addresses it generically in the core instead of per-generator.

The implementation is inspired by #19473, where operations were divided by content-type. The key difference here: the division is gated behind an opt-in option (splitOperationsByContentType, default false), so all existing generator outputs are unchanged and no current codegen is broken.

Why it is off by default

Some dynamically- or structurally-typed languages can already represent several input/return types within a single operationId, so splitting would be unnecessary (or even undesirable) for them:

• Python deserializes the response body from the actual Content-Type at runtime and returns a dynamically-typed object (see Adds request body content data to allow multiple content types to be sent to servers #10973 / Adds python-experimental which uses dynamic base classes #8325).
• Ruby maps the status / content-type to the return type at runtime in a single method ([Ruby] Incorrect return types if multiple responses are defined (reopened) #8431).
• TypeScript expresses it as a union return type, e.g. TypeA | TypeB, in a single method signature ([TS][Angular] better handling of multiple responses #13426).

Statically-typed / compiled languages (Java, C#, Go, Kotlin, Swift, ...) cannot overload a method by return type, so they benefit from one typed method per content-type — which is exactly what this option produces when enabled. Keeping it opt-in lets each consumer decide, without changing any default
output.

How it works

When the option is enabled, DefaultCodegen#preprocessOpenAPI divides an eligible operation into the cartesian product of its request-body and success-response content-types (deduplicated by schema). Each variant is a narrowed OpenAPI Operation (a single content-type on each axis) with a typed,
collision-free operationId — request appends With<Subtype> and response appends As<Subtype> (e.g. createReportWithXmlAsPdf). The variants are stored on the original operation under the x-content-type-variants extension and expanded by DefaultGenerator#processOperation, so each one re-enters
fromOperation and is typed natively by the target generator. The feature is therefore language-neutral: no per-language type re-derivation and no template changes.

Tests

Added unit tests in DefaultCodegenTest: the request×response cartesian (4 variants), the response-only case (2 variants), and a check that unambiguous operations are left untouched.

PR checklist

• [ X ] Read the contribution guidelines.
• [ X ] 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.
• [ X ] If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

Technical committee mention

This feature is opt-in and primarily benefits statically-typed / compiled generators, which cannot overload a method by return type and therefore gain one typed method per content-type. cc the relevant technical committee members:

• Java: @bbdouglas@sreeshas@jfiala@lukoyanov@cbornet@jeff9finger@karismann@Zomzog@lwlee2608@martin-mfg
• Java Spring: @cachescrubber@welshm@MelleD@atextor@manedev79@javisst@borsch @banlevente
• Kotlin: @andrewemery@4brunu @yutaka0m @stefankoppier@e5l@dennisameling
• C#: @mandrean@shibayan@Blackclaws@lucamazzanti@iBicha
• Go: @antihax@grokify@kemokemo@jirikuncar@ph4r5h4d@lwj5
• Rust: @frol@farcaller@richardwhiuk@paladinzh@jacob-pro@dsteeley
• Swift: @jgavris@ehyche@Edubits@jaz-ah@dydus0x14
• C++: @ravinikam@stkrwork@etherealjoy@MartinDelille @muttleyxd @aminya
• C: @zhemant @ityuhui @michelealbano @eafer
• Scala: @clasnake @shijinkui @ramzimaalej @chameleon82 @Bouillie @fish86
• Dart: @jaumard @josh-burton @amondnet @sbu-WBT @kuhnroyal @agilob @ahmednfwela
• F#: @nmfisher
• Crystal: @cyangle

---

Summary by cubic

Adds an opt-in global splitOperationsByContentType to split operations by request/response content-type when schemas differ. Defaults to off; typescript-fetch merges variants into one precisely typed method, and the sample/docs were refined to show all media types and case-insensitive matching.

• New Features

  • Global splitOperationsByContentType (default false), documented in global-properties.md; enable with --global-property splitOperationsByContentType=true.
  • Core: DefaultGenerator#processOperation delegates to the config to split; DefaultCodegen emits deduped request×response variants with collision-free ids and variant-index extensions.
  • typescript-fetch: merges variants into one method (request is a union discriminated by contentType; response typed via accept overloads). Adds ExclusiveUnion in runtime.mustache; extracts form params to apisFormParams.mustache and adds small partials to support the merge while keeping legacy output byte-identical when the option is off.
  • New sample and config: bin/configs/typescript-fetch-split-by-content-type.yaml and a typescript-fetch petstore sample with the option on; included in CI typecheck to catch regressions. Tests cover enums, forms, optional/no-body responses, and name collisions.
  • Docs/sample: merged-method docs now list the full request/response media-type union; sample switches XML to application/merge-patch+json; docs clarify this option chooses which media types get operations and does not add new encoders.

• Bug Fixes

  • typescript-fetch: compare response Content-Type case-insensitively to pick the right deserializer.
  • Petstore resttemplate-springBoot4-jackson3 sample: set spring-web to 7.0.5 to fix build.

^{Written for commit eec586e. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 138 files

<sub>Note: This PR contains a large number of files. cubic only reviews up to 100 files per PR, so some files may not have been reviewed. cubic prioritizes the most important files to review.
On a pro plan you can use ultrareview for larger PRs.

Re-trigger cubic</sub>

[AntoineDuComptoirDesPharmacies]

Hello @wing328,

I know you express your good feeling about dividing operations to manage this use case. (See : #19473)

Do not hesisaste to give me your point of view about this big change (opt-in) that would solve the problem for multiple langages.

Yours faithfully,
LCDP

[wing328]

please PM me via Slack to further discuss this to move this PR forward when you've time.

https://join.slack.com/t/openapi-generator/shared_invite/zt-36ucx4ybl-jYrN6euoYn6zxXNZdldoZA

[cubic-dev-ai]

All reported issues were addressed across 30 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

1 issue found across 20 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptFetchClientCodegen.java">
<violation number="1" location="modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptFetchClientCodegen.java:1093">
P3: Generated API documentation can list response media types in a different order from the OpenAPI response declaration when another response status has content: each narrowed variant carries all response-status media types, so `mediaTypesOf` interleaves them as it walks variants. Preserving the pre-split response media-type order would avoid this documentation regression.</violation>
</file>

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

P3: Generated API documentation can list response media types in a different order from the OpenAPI response declaration when another response status has content: each narrowed variant carries all response-status media types, so mediaTypesOf interleaves them as it walks variants. Preserving the pre-split response media-type order would avoid this documentation regression.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptFetchClientCodegen.java, line 1093:
<comment>Generated API documentation can list response media types in a different order from the OpenAPI response declaration when another response status has content: each narrowed variant carries all response-status media types, so `mediaTypesOf` interleaves them as it walks variants. Preserving the pre-split response media-type order would avoid this documentation regression.</comment>
<file context>
@@ -1084,13 +1085,39 @@ private void mergeContentTypeVariants(OperationsMap operations) {
+ // request axis was not split - a case where this union is the single value anyway - and never
+ // reads produces, so this is documentation only.
+ base.consumes = mediaTypesOf(requestVariants, v -> v.consumes);
+ base.produces = mediaTypesOf(responseVariants, v -> v.produces);
+
variants.stream().filter(op -> op != base).forEach(superseded::add);
</file context>

[AntoineDuComptoirDesPharmacies]

It's only mixing the order of generation, only esthetic, i propose not to fix this.

[wing328]

ran some tests locally and the results are good

let's give it a try

thanks for your contribution.

[jschonenberg]

@AntoineDuComptoirDesPharmacies thank you for your work!

Since splitOperationsByContentType was added as a global property, I would assume that it would automatically be available for all generators.
However, we are using the java generator and the property does not seem to be effective.

Is this as expected? Is it due to how the java generator is implemented?

[AntoineDuComptoirDesPharmacies]

This PR adds an opt-in splitOperationsByContentType option that fixes#6708: an operation may expose several request and/or response content-types with different schemas, but generators currently keep only the first one ("Multiple schemas found in the OAS 'content' section, returning only the first").
The result is a single, mistyped method, and the other content-types are unreachable.

The same underlying problem has been reported and worked around in a language-specific way in several places — e.g. #22095 (rust-axum), #8431 (Ruby), #13426 (TypeScript/Angular) and #10973 (Python request bodies). This PR addresses it generically in the core instead of per-generator.

The implementation is inspired by #19473, where operations were divided by content-type. The key difference here: the division is gated behind an opt-in option (splitOperationsByContentType, default false), so all existing generator outputs are unchanged and no current codegen is broken.

Why it is off by default

Some dynamically- or structurally-typed languages can already represent several input/return types within a single operationId, so splitting would be unnecessary (or even undesirable) for them:

• Python deserializes the response body from the actual Content-Type at runtime and returns a dynamically-typed object (see Adds request body content data to allow multiple content types to be sent to servers #10973 / Adds python-experimental which uses dynamic base classes #8325).
• Ruby maps the status / content-type to the return type at runtime in a single method ([Ruby] Incorrect return types if multiple responses are defined (reopened) #8431).
• TypeScript expresses it as a union return type, e.g. TypeA | TypeB, in a single method signature ([TS][Angular] better handling of multiple responses #13426).

Statically-typed / compiled languages (Java, C#, Go, Kotlin, Swift, ...) cannot overload a method by return type, so they benefit from one typed method per content-type — which is exactly what this option produces when enabled. Keeping it opt-in lets each consumer decide, without changing any default
output.

How it works

When the option is enabled, DefaultCodegen#preprocessOpenAPI divides an eligible operation into the cartesian product of its request-body and success-response content-types (deduplicated by schema). Each variant is a narrowed OpenAPI Operation (a single content-type on each axis) with a typed,
collision-free operationId — request appends With<Subtype> and response appends As<Subtype> (e.g. createReportWithXmlAsPdf). The variants are stored on the original operation under the x-content-type-variants extension and expanded by DefaultGenerator#processOperation, so each one re-enters
fromOperation and is typed natively by the target generator. The feature is therefore language-neutral: no per-language type re-derivation and no template changes.

Tests

Added unit tests in DefaultCodegenTest: the request×response cartesian (4 variants), the response-only case (2 variants), and a check that unambiguous operations are left untouched.

PR checklist

• [ X ] Read the contribution guidelines.
• [ X ] 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.
• [ X ] If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

Technical committee mention

This feature is opt-in and primarily benefits statically-typed / compiled generators, which cannot overload a method by return type and therefore gain one typed method per content-type. cc the relevant technical committee members:

• Java: @bbdouglas@sreeshas@jfiala@lukoyanov@cbornet@jeff9finger@karismann@Zomzog@lwlee2608@martin-mfg
• Java Spring: @cachescrubber@welshm@MelleD@atextor@manedev79@javisst@borsch @banlevente
• Kotlin: @andrewemery@4brunu @yutaka0m @stefankoppier@e5l@dennisameling
• C#: @mandrean@shibayan@Blackclaws@lucamazzanti@iBicha
• Go: @antihax@grokify@kemokemo@jirikuncar@ph4r5h4d@lwj5
• Rust: @frol@farcaller@richardwhiuk@paladinzh@jacob-pro@dsteeley
• Swift: @jgavris@ehyche@Edubits@jaz-ah@dydus0x14
• C++: @ravinikam@stkrwork@etherealjoy@MartinDelille @muttleyxd @aminya
• C: @zhemant @ityuhui @michelealbano @eafer
• Scala: @clasnake @shijinkui @ramzimaalej @chameleon82 @Bouillie @fish86
• Dart: @jaumard @josh-burton @amondnet @sbu-WBT @kuhnroyal @agilob @ahmednfwela
• F#: @nmfisher
• Crystal: @cyangle

---

Summary by cubic

Adds an opt-in global splitOperationsByContentType to split operations by request/response content-type when schemas differ. Defaults to off; typescript-fetch merges variants into one precisely typed method, and the sample/docs were refined to show all media types and case-insensitive matching.

• New Features

  • Global splitOperationsByContentType (default false), documented in global-properties.md; enable with --global-property splitOperationsByContentType=true.
  • Core: DefaultGenerator#processOperation delegates to the config to split; DefaultCodegen emits deduped request×response variants with collision-free ids and variant-index extensions.
  • typescript-fetch: merges variants into one method (request is a union discriminated by contentType; response typed via accept overloads). Adds ExclusiveUnion in runtime.mustache; extracts form params to apisFormParams.mustache and adds small partials to support the merge while keeping legacy output byte-identical when the option is off.
  • New sample and config: bin/configs/typescript-fetch-split-by-content-type.yaml and a typescript-fetch petstore sample with the option on; included in CI typecheck to catch regressions. Tests cover enums, forms, optional/no-body responses, and name collisions.
  • Docs/sample: merged-method docs now list the full request/response media-type union; sample switches XML to application/merge-patch+json; docs clarify this option chooses which media types get operations and does not add new encoders.

• Bug Fixes

  • typescript-fetch: compare response Content-Type case-insensitively to pick the right deserializer.
  • Petstore resttemplate-springBoot4-jackson3 sample: set spring-web to 7.0.5 to fix build.

^{Written for commit eec586e. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 138 files

<sub>Note: This PR contains a large number of files. cubic only reviews up to 100 files per PR, so some files may not have been reviewed. cubic prioritizes the most important files to review.
On a pro plan you can use ultrareview for larger PRs.

Re-trigger cubic</sub>

[AntoineDuComptoirDesPharmacies]

Hello @wing328,

I know you express your good feeling about dividing operations to manage this use case. (See : #19473)

Do not hesisaste to give me your point of view about this big change (opt-in) that would solve the problem for multiple langages.

Yours faithfully,
LCDP

[wing328]

please PM me via Slack to further discuss this to move this PR forward when you've time.

https://join.slack.com/t/openapi-generator/shared_invite/zt-36ucx4ybl-jYrN6euoYn6zxXNZdldoZA

[cubic-dev-ai]

All reported issues were addressed across 30 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

1 issue found across 20 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptFetchClientCodegen.java">
<violation number="1" location="modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptFetchClientCodegen.java:1093">
P3: Generated API documentation can list response media types in a different order from the OpenAPI response declaration when another response status has content: each narrowed variant carries all response-status media types, so `mediaTypesOf` interleaves them as it walks variants. Preserving the pre-split response media-type order would avoid this documentation regression.</violation>
</file>

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

P3: Generated API documentation can list response media types in a different order from the OpenAPI response declaration when another response status has content: each narrowed variant carries all response-status media types, so mediaTypesOf interleaves them as it walks variants. Preserving the pre-split response media-type order would avoid this documentation regression.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/TypeScriptFetchClientCodegen.java, line 1093:
<comment>Generated API documentation can list response media types in a different order from the OpenAPI response declaration when another response status has content: each narrowed variant carries all response-status media types, so `mediaTypesOf` interleaves them as it walks variants. Preserving the pre-split response media-type order would avoid this documentation regression.</comment>
<file context>
@@ -1084,13 +1085,39 @@ private void mergeContentTypeVariants(OperationsMap operations) {
+ // request axis was not split - a case where this union is the single value anyway - and never
+ // reads produces, so this is documentation only.
+ base.consumes = mediaTypesOf(requestVariants, v -> v.consumes);
+ base.produces = mediaTypesOf(responseVariants, v -> v.produces);
+
variants.stream().filter(op -> op != base).forEach(superseded::add);
</file context>

[AntoineDuComptoirDesPharmacies]

It's only mixing the order of generation, only esthetic, i propose not to fix this.

[wing328]

ran some tests locally and the results are good

let's give it a try

thanks for your contribution.

[jschonenberg]

@AntoineDuComptoirDesPharmacies thank you for your work!

Since splitOperationsByContentType was added as a global property, I would assume that it would automatically be available for all generators.
However, we are using the java generator and the property does not seem to be effective.

Is this as expected? Is it due to how the java generator is implemented?