[Kotlin-client] fix kotlin code client generator for oneOf with allOf

[bykakashka]

Removed children params from parent model in case of oneOf + allOf usage. Fixes #24164

PR checklist

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

---

Summary by cubic

Fixes Kotlin client codegen for polymorphic oneOf + allOf with discriminators by preventing child properties from merging into parent models. Keeps oneOf/anyOf form-data parameters generating fields correctly across jackson, moshi, gson, and kotlinx_serialization.

• Bug Fixes
  • Enable skipOneOfPropertyMergeInParent = true in KotlinClientCodegen (constructor) for all serializers; move flag from AbstractKotlinCodegen and decouple from supportsInheritance.
  • Simplify DefaultCodegen: treat oneOf/anyOf as alternatives when the flag is on (no child-property merge into parents even with discriminators); add a flattening path so form-data oneOf/anyOf params still produce individual fields; update ProtobufSchemaCodegen override to the new addProperties signature.
  • Add parameterized tests for all serializers: plain oneOf wrapper, oneOf with discriminator (no leak), plain allOf (inheritance preserved), allOf with discriminator (no leak), and mixed allOf/oneOf with discriminator.
  • Regenerate samples and docs; minor TypeScript Fetch guard tightening.

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

[cubic-dev-ai]

3 issues found across 4 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

1 issue found across 4 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/KotlinClientCodegen.java">

<violation number="1" location="modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/KotlinClientCodegen.java:311">
P2: Setting `skipOneOfPropertyMergeInParent = true` unconditionally in the KotlinClientCodegen constructor affects all oneOf/anyOf schemas, not just the oneOf+allOf case described in the PR. In `DefaultCodegen.addProperties()`, this flag prevents merging oneOf AND anyOf child properties into parent models globally. Since KotlinClientCodegen only supports oneOf/anyOf wrappers for `jvm-retrofit2` with `gson`/`kotlinx_serialization`, and the default is `jvm-okhttp4` with `moshi`, plain oneOf/anyOf schemas under default or unsupported configurations may lose child properties with no wrapper fallback. Consider scoping this flag to the specific oneOf+allOf/discriminator case or to library/serialization combinations that provide wrapper support.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P2: Setting skipOneOfPropertyMergeInParent = true unconditionally in the KotlinClientCodegen constructor affects all oneOf/anyOf schemas, not just the oneOf+allOf case described in the PR. In DefaultCodegen.addProperties(), this flag prevents merging oneOf AND anyOf child properties into parent models globally. Since KotlinClientCodegen only supports oneOf/anyOf wrappers for jvm-retrofit2 with gson/kotlinx_serialization, and the default is jvm-okhttp4 with moshi, plain oneOf/anyOf schemas under default or unsupported configurations may lose child properties with no wrapper fallback. Consider scoping this flag to the specific oneOf+allOf/discriminator case or to library/serialization combinations that provide wrapper support.

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/KotlinClientCodegen.java, line 311:

<comment>Setting `skipOneOfPropertyMergeInParent = true` unconditionally in the KotlinClientCodegen constructor affects all oneOf/anyOf schemas, not just the oneOf+allOf case described in the PR. In `DefaultCodegen.addProperties()`, this flag prevents merging oneOf AND anyOf child properties into parent models globally. Since KotlinClientCodegen only supports oneOf/anyOf wrappers for `jvm-retrofit2` with `gson`/`kotlinx_serialization`, and the default is `jvm-okhttp4` with `moshi`, plain oneOf/anyOf schemas under default or unsupported configurations may lose child properties with no wrapper fallback. Consider scoping this flag to the specific oneOf+allOf/discriminator case or to library/serialization combinations that provide wrapper support.</comment>

<file context>
@@ -307,6 +307,8 @@ public KotlinClientCodegen() {
         cliOptions.add(CliOption.newBoolean(USE_JACKSON_3,
             "Use Jackson 3 dependencies (tools.jackson package). Not yet supported for kotlin-client; reserved for future use."));
+
+        skipOneOfPropertyMergeInParent = true;
     }
 
</file context>

[bykakashka]

The bug affects all serialization libraries equally. Without the fix, moshi, gson, and kotlinx_serialization all produce identical broken output — fat parent interfaces with leaked child properties and sibling contamination.

Plain oneOf without discriminator is NOT affected. These schemas generate a data class wrapper (not an interface), and addProperties() merging is correct — the wrapper IS supposed to contain all variant properties as a union type. Tested and confirmed.

Plain allOf without discriminator is NOT affected. Standard inheritance works identically with and without the fix.

Added 16 new parameterized tests covering all 4 patterns (plain oneOf, oneOf+discriminator, plain allOf, allOf+discriminator) × all 4 serialization libraries (jackson, moshi, gson, kotlinx_serialization) — all pass. The flag is safe to set unconditionally at the KotlinClientCodegen level.

[cubic-dev-ai]

1 issue found across 1 file (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/KotlinClientCodegen.java">

<violation number="1" location="modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/KotlinClientCodegen.java:311">
P2: Setting `skipOneOfPropertyMergeInParent = true` unconditionally in the KotlinClientCodegen constructor affects all oneOf/anyOf schemas, not just the oneOf+allOf case described in the PR. In `DefaultCodegen.addProperties()`, this flag prevents merging oneOf AND anyOf child properties into parent models globally. Since KotlinClientCodegen only supports oneOf/anyOf wrappers for `jvm-retrofit2` with `gson`/`kotlinx_serialization`, and the default is `jvm-okhttp4` with `moshi`, plain oneOf/anyOf schemas under default or unsupported configurations may lose child properties with no wrapper fallback. Consider scoping this flag to the specific oneOf+allOf/discriminator case or to library/serialization combinations that provide wrapper support.</violation>
</file>

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

Re-trigger cubic</sub>

[wing328]

please follow step 3 to update the samples

[cubic-dev-ai]

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

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

Re-trigger cubic</sub>

[bykakashka]

please follow step 3 to update the samples

updated samples & fixed generation for form-data

[Mattias-Sehlstedt]

Rather than extending the behavior of the DefaultCodegen would it not make more sense to have the Kotlin generator interpret the Codegen structure differently for Interface and Model?

So that the Codegen is always populated with parameters that might be needed in order to express different hierarchies, but different cases read these differently. I.e., Interface is a view that only reads X and Model reads Y.

the Java client generator has long only generated a basic interface with only the discriminator property, but people have been asking if it can be extended with more shared variables. Making it so that the Codegen model better captures where it got the properties from would enable both of these scenarios to work much better, and we would have a shared DefaultCodegen that each language then used to the extend that the language allows?

Having a boolean seems unnatural to me, and especially the fact that we have to force it to true in certain places. It feels more natural to have "ignore properties Z since we are building a serialization interface" in the Kotlin generator.

---

Could you share the generator settings that you use? I can see that there for example exist generateOneOfAnyOfWrappers: true. To me it seems like the basic interface definition is just a unsuited for being part of data_class.mustache, and that there are already some different ways that people have tried to tackle that?

[bykakashka]

Rather than extending the behavior of the DefaultCodegen would it not make more sense to have the Kotlin generator interpret the Codegen structure differently for Interface and Model?

kinda yes, but the main issue is 'updateModelForComposedSchema' which adds all the children params into CodegenModel.vars. WWe can add a new field smth like 'childerVars' and use it in lang-specific mustache/generators if needed, to replicate current output. But I'm not so confident in refactoring this functionality for all languages. I can try tho

Could you share the generator settings that you use?

default settings as in testOneOfAllOfDiscriminatorInheritancePropertiesNotLeakedToParent test

[Mattias-Sehlstedt]

I believe a part of the issue too is that your specification is using a structure that is generally harder than necessary to interpret and reason about. This since you have infinite recursion with the oneOf -> allOf -> oneOf -> allOf -> ...

I personally always do either an allOf inheritance for the polymorphic structure or the oneOf. This both to integrate well with tooling for code generation but also to get a correct visual presentation (e.g., in swagger-ui). This is currently presented in swagger-ui as:

If you are using springdoc-openapi to generate the specification yourself then I should be able to provide some way of handling this better.

You can see the difference between the two ways in the OAS examples, with oneOf and allOf.

[bykakashka]

hm, my bad. somehow I missed the diff between my old openapi spec and spring generated one ... I'll play with spring openapi generator, and will close this MR/ticket
thanks!