OpenAPITools / OpenAPITools/openapi-generator
[BUG] Property isEnum false for referenced ENUM schemas
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 26.8k
- Forks
- 7.7k
- PR merge metrics
- PR metrics pending
Description
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?
- Have you search for related issues/PRs?
- What's the actual output vs expected output?
Description
When generating the code of the Erlang server, I have noticed that the ENUM check would not work on one parameter. By reducing the file I found out that the generator wasn't putting the enum values in the generated code, not because allowableValues was null but because isEnum was set on false for referenced ENUM parameters.
openapi-generator version
4.0.0, commit b426bab
OpenAPI declaration file content or url
openapi: '3.0.0'
info:
version: 1.0.0
title: Enums Issue
paths:
/test:
get:
operationId: TestEnum
parameters:
- name: paramA
in: query
required: true
schema:
$ref: '#/components/schemas/EnumString'
- name: paramB
in: query
required: true
schema:
type: string
enum:
- first
- second
- third
responses:
default:
description: unexpected error
content:
application/json:
schema:
type: object
properties:
message:
type: string
components:
schemas:
EnumString:
type: string
enum:
- first
- second
- third
Command line used for generation
java -jar openapi-generator-cli.jar -i enums.yaml -g erlang-server -o server/
Steps to reproduce
- Create the file enums.yaml
- Generate the code with the command
- Open server/src/openapi_api.erl, look at function
request_param_info(line 52) - Compare the param infos of paramA and paramB
Obtained result:
request_param_info('TestEnum', 'paramA') ->
#{
source => qs_val ,
rules => [
required
]
};
request_param_info('TestEnum', 'paramB') ->
#{
source => qs_val ,
rules => [
{type, 'binary'},
{enum, ['first', 'second', 'third'] },
required
]
};
Expected result:
request_param_info('TestEnum', 'paramA') ->
#{
source => qs_val ,
rules => [
{type, 'binary'},
{enum, ['first', 'second', 'third'] },
required
]
};
request_param_info('TestEnum', 'paramB') ->
#{
source => qs_val ,
rules => [
{type, 'binary'},
{enum, ['first', 'second', 'third'] },
required
]
};
Suggest a fix
In DefaultCodegen, fromProperty, adding property.isEnum= true; at line 2068 after assigning allowableValues seems to fix the issue of the missing enum values, but doesn't assign any type to the property. To fix that I would move the type checking block right over the inline enum case as a function protected void setPropertyType(CodegenProperty property, Schema p, String name) and add two calls, one for p (setPropertyType(property, p, name)) and one for referencedSchema (setPropertyType(property, referencedSchema, name).
//Referenced enum case:
if (referencedSchema.getEnum() != null && !referencedSchema.getEnum().isEmpty()) {
List<Object> _enum = referencedSchema.getEnum();
Map<String, Object> allowableValues = new HashMap<String, Object>();
allowableValues.put("values", _enum);
if (allowableValues.size() > 0) {
property.allowableValues = allowableValues;
property.isEnum = true;
}
}
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
Start with DefaultCodegen.fromProperty and the referenced-enum handling described in the issue. Reproduce with enums.yaml using the openapi-generator-cli command, then compare request_param_info for paramA and paramB in server/src/openapi_api.erl. Done means both referenced and inline enum parameters include the type and enum rules.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- erlang, java
- Domain
- backend-api-design, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 45/100