[BUG][JAVA][JAVASCRIPT] When request body have multiple content types, method for only one content type is created
Bug Report Checklist
- [x] Have you provided a full/minimal spec to reproduce the issue?
- [x] Have you validated the input using an OpenAPI validator (example)?
- [x] Have you tested with the latest master to confirm the issue still exists?
- [x] Have you searched for related issues/PRs?
- [x] What's the actual output vs expected output?
- [ ] [Optional] Sponsorship to speed up the bug fix or feature request (example)
Description
When a path have multiple content types in its request body, only a single method is created for a single content. Which makes it to not be able to create request for non generated content types, especially if they have different schema. According to OpenAPI spec, request body can have multiple content types. Openapi-Generator also have an example spec file with multiple content type with different schema.
Expected behaviour is separate method for each content type is generated.
openapi-generator version
Tried with both 7.2 and 7.3
OpenAPI declaration file content or url
openapi: 3.0.3
info:
version: "1"
title: Multiple Content Types for same request
paths:
/multiplecontentpath:
post:
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/coordinates'
mutlipart/form-data:
schema:
type: object
properties:
coordinates:
$ref: '#/components/schemas/coordinates'
file:
type: string
format: binary
responses:
201:
description: Successfully created
headers:
Location:
schema:
type: string
components:
schemas:
coordinates:
type: object
required:
- lat
- long
properties:
lat:
type: number
long:
type: number
Using this spec, method for only application/json will be created. If you put the mutipart/form-data first, only method for multipart will be created.
Generation Details
inputSpec: multiple-content.yaml
outputDir: feign
generatorName: java
additionalProperties:
library: feign
inputSpec: multiple-content.yaml
outputDir: jersey3
generatorName: java
additionalProperties:
library: jersey3
I have also tried native, helidon, micronaut for java, all resulting same problem. For curiosity tried typescript-fetch and android, this also resulted is a single method.
Steps to reproduce
- Generate code using the provided OpenAPI spec and configuration.
- Check generated source codes for API.
Related issues/PRs
Suggest a fix
I am not sure what is wrong. But it might be something problematic in higher up in the generation chain. As not only the java but also JavaScript, android generator had the same problem. Other generator might have the same problem which I did not look into.
@mirzaprangon for your use cases, can you please PM me via Slack for few quick questions when you've time?
https://join.slack.com/t/openapi-generator/shared_invite/zt-12jxxd7p2-XUeQM~4pzsU9x~eGLQqX2g
Hello, just FYI, it's the same problem for responses
'200':
description: The document
content:
application/json:
schema:
$ref: '#/components/schemas/Document'
text/markdown:
schema:
type: string
description: the markdown content
Would generate a return type for the first one only.
Also here have the same scenario described by @mirzaprangon Do you think to fix it asap?
Work around suggestion while waiting fix.
- create specific path for each content type, specifing an operationId.
openapi: 3.0.3
info:
version: "1"
title: Multiple Content Types for same request
paths:
/multiplecontentpath/applicationjson:
post:
operationId: multipleContentPath_json
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/coordinates'
responses:
201:
description: Successfully created
headers:
Location:
schema:
type: string
/multiplecontentpath/mutlipartformdata:
post:
operationId: multipleContentPath_multipart
requestBody:
content:
mutlipart/form-data:
schema:
type: object
properties:
coordinates:
$ref: '#/components/schemas/coordinates'
file:
type: string
format: binary
responses:
201:
description: Successfully created
headers:
Location:
schema:
type: string
components:
schemas:
coordinates:
type: object
required:
- lat
- long
properties:
lat:
type: number
long:
type: number
In this way when the bug is fixed you can use your original swagger definition - same path with different content type - and yours client application must only download the new version of released autogenerated client, but no code changes needed because the function name will be the same.
Any update on this one? Any workarounds without having to change the contract?