[cmuchinsky]

fix #25226

When the discriminator property of all the subtypes mapped by a oneOf is a $ref to the same alias of a primitive type (e.g. ShapeKind: {type: string}), DefaultCodegen#getCommonSchemaType (added by #24812) returns the name of the alias schema as the type of the getter of the generated oneOf interface. No model is generated for such an alias, so the generated code does not compile, while the subtypes use String:

public interface Shape {
    public ShapeKind getKind();   // error: cannot find symbol, class ShapeKind (7.25.0: public String getKind();)
}

The schema is now unaliased first, like getSingleSchemaType does for the property type of the subtypes. A $ref that is still present afterwards (enum, object, composed schema, schemaMappings target) is still used as a model name, so the behavior added by #24812 for enums is unchanged. Aliases of primitive types resolve to the aliased type (String, Integer, UUID, ...).

Tests

• New spec oneOf_issue_25226.yaml with one oneOf per case: shared string alias, integer alias, format: uuid alias, alias of an alias, alias of an enum, direct $ref to an enum, one alias per subtype, alias inherited through allOf.
• DefaultCodegenTest#testOneOfDiscriminatorPropertyIsRefToPrimitiveAlias (discriminator property type) and SpringCodegenTest#issue_25226 (generated interfaces and models). Both fail without the change (e.g. Shape ==> expected: <String> but was: <ShapeKind>) and pass with it.
• ./mvnw -pl modules/openapi-generator -am test: 5361 tests, 0 failures (14 skipped, @Ignored upstream).
• ./bin/generate-samples.sh ./bin/configs/*.yaml (all 827 configs) and ./bin/utils/export_docs_generators.sh: no change under samples/ or docs/.

PR checklist

• Read the contribution guidelines.
• Run the following to build the project and update samples (the CLI was built with ./mvnw -pl modules/openapi-generator-cli -am package -DskipTests, and the tests of modules/openapi-generator were run as above):

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  No file needed to be updated.
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request. (This is a core change that affects the generators with oneOf interfaces, i.e. the Java family) cc @jpfinne @Mattias-Sehlstedt (fix(core) handle mismatching discriminatorType in oneOf interfaces #24812), @wing328 @cbornet

🤖 Generated with Claude Code

---

Summary by cubic

Fixes #25226. When all subtypes of a oneOf use a $ref to the same alias of a primitive type as the discriminator property, the generated oneOf interface now uses the aliased type (e.g. String) instead of the missing alias schema name, which previously broke compilation. The change unaliases the schema in DefaultCodegen#getCommonSchemaType; aliases to enums and composed schemas still resolve to model names, preserving the behavior introduced in #24812.

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

[cubic-dev-ai]

No issues found across 4 files

_{View guided diff | Re-trigger cubic}

[Mattias-Sehlstedt]

How does/should this play with generateAliasAsModel from https://openapi-generator.tech/docs/globals/?

[cmuchinsky]

Good question. For aliases of primitive types there is no interaction: generateAliasAsModel (and x-generate-alias-as-model) only applies to array and map aliases (ModelUtils.unaliasSchema, shouldGenerateArrayModel/shouldGenerateMapModel). Primitive aliases are always flagged isAlias and never generated as models, and unaliasSchema always resolves them, so the discriminator getter gets the aliased type in both modes. I checked by generating the new spec with and without --generate-alias-as-model: identical output, no alias model.

The change delegates to unaliasSchema, so whatever the flag decides for an alias is applied to the getter, exactly as for the property type of the subtypes. For an array or map alias used as the discriminator property (not a meaningful discriminator, I only tried it to exercise the branch): with the flag the alias is a model and its name is kept (unchanged), without it the alias resolves to List/Map, which compile against the subtypes.

I can add a test that runs the new spec with the flag set if you'd like.