OpenAPITools / OpenAPITools/openapi-generator
[BUG] Code is not generated correctly for allOf.
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 26.8k
- Forks
- 7.7k
- PR merge metrics
- PR metrics pending
Description
Description
I am not able to get the following definition to generate java or type script correctly.
Have tried with 4.3.1.
In Java, RealCommand is generated as
public class RealCommand extends Command {
...
}
Notice that I did not specify a discriminator in Command. I expect this definition to generate a composition of Command and RealCommand.java and that Command.java would not be generated. Command.java file is not generated, but it is also expected as a base class in RealCommand.java, so this does not compile.
There should not be any inheritance here because there is no discriminator.
openapi-generator version
4.3.1
Bug Report Checklist
- Have you provided a full/minimal spec to reproduce the issue?
- Have you validated the input using an OpenAPI validator (example)?
- What's the version of OpenAPI Generator used? - 4.3.1
- Have you search for related issues/PRs? - yes
- What's the actual output vs expected output?
- [Optional] Bounty to sponsor the fix (example)
OpenAPI declaration file content or url
swagger: "2.0"
info:
title: Test Command model generation
description: Test Command model generation
version: 1.0.0
host: localhost:8080
schemes:
- https
definitions:
Command:
title: Command
description: The base object for all command objects.
x-swagger-router-model: CommandDto
type: object
properties: {}
RealCommand:
title: RealCommand
description: The real command.
x-swagger-router-model: RealCommandDto
allOf:
- $ref: '#/definitions/Command'
ApiError:
description: The base object for API errors.
x-swagger-router-model: ApiGeneralException
type: object
required:
- code
- message
properties:
code:
description: The error code. Usually, it is the HTTP error code.
type: string
readOnly: true
message:
description: The error message.
type: string
readOnly: true
title: ApiError
parameters:
b_real_command:
name: real_command
in: body
description: A payload for executing a real command.
required: true
schema:
$ref: '#/definitions/RealCommand'
paths:
/execute:
post:
produces: []
x-swagger-router-controller: FakeController
operationId: executeRealCommand
parameters:
- name: real_command
in: body
description: A payload for executing a real command.
required: true
schema:
$ref: '#/definitions/RealCommand'
responses:
'204':
description: Successful request. No content returned.
'400':
description: Bad request.
schema:
$ref: '#/definitions/ApiError'
'404':
description: Not found.
schema:
$ref: '#/definitions/ApiError'
default:
description: Unknown error.
schema:
$ref: '#/definitions/ApiError'
Command line used for generation
openapi-generator generate -i test.yaml -g java --library jersey2 -o java --additional-properties legacyDiscriminatorBehavior=false
Steps to reproduce
Related issues/PRs
https://github.com/OpenAPITools/openapi-generator/issues/2845
Suggest a fix
I see that maybe ModelUtils#isFreeFormObject() should also check to see if the object is used in an allOf, anyOf, or oneOf in any other schema in the definition.
But this still does not explain why RealCommand is using Command as a base class.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the issue with the provided YAML and the shown openapi-generator command, then trace ModelUtils#isFreeFormObject() and the model-generation path for allOf schemas. Compare the Java and TypeScript output for RealCommand and Command. Done means the generated models do not reference an ungenerated Command base class and the output compiles correctly.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, openapi, typescript
- Domain
- backend-api-design, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100