OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3)
[ ] [Optional] Sponsorship to speed up the bug fix or feature request (example)
Description
The breaking change introduced in #9331 (in a fix version!) applies not only to in-Parameters but also to out-Parameters. The result is that 5.1.1 cannot be applied for projects having application/octet-stream as response parameters. It is not only a breaking change (requiring source code change) the results in compile errors, these errors cannot be fixed, as MultipartFile is not a valid return value.
After the Change the generated API is this:
/**
* GET /downloadFile/{fileId} : File for an ID
* Retrieves file.
*
* @param fileId Numeric ID of the file. (required)
* @return OK (status code 200)
*/
@ApiOperation(value = "File for an ID", nickname = "getFile", notes = "Retrieves file.", response = org.springframework.web.multipart.MultipartFile.class, tags={ "files", })
@ApiResponses(value = {
@ApiResponse(code = 200, message = "OK", response = org.springframework.web.multipart.MultipartFile.class) })
@GetMapping(
value = "/downloadFile/{fileId}",
produces = { "application/octet-stream" }
)
default ResponseEntity<org.springframework.web.multipart.MultipartFile> getFile(@ApiParam(value = "Numeric ID of the file.",required=true) @PathVariable("fileId") Long fileId) {
return new ResponseEntity<>(HttpStatus.NOT_IMPLEMENTED);
}
Before Version 5.1.1 it was:
default ResponseEntity<org.springframework.core.io.Resource> getFile(@ApiParam(value = "Numeric ID of the file.",required=true) @PathVariable("fileId") Long fileId)
However, the newly generated interface contract cannot be satisfied in a clean way, as MultipartFile is not supposed to be a return value. See Spring documentation of MultipartFile
A representation of an uploaded file received in a multipart request.
The file contents are either stored in memory or temporarily on disk. In either case, the user is responsible for copying file contents to a session-level or persistent store as and if desired. The temporary storage will be cleared at the end of request processing.
openapi-generator version
5.1.1
OpenAPI declaration file content or url
get:
tags:
- files
summary: File for an ID
description: Retrieves file.
operationId: getFile
parameters:
- in: path
name: fileId
schema:
type: integer
format: int64
required: true
description: Numeric ID of the file.
responses:
200:
description: OK
content:
application/octet-stream:
schema:
type: string
format: binary
Bug Report Checklist
Description
The breaking change introduced in #9331 (in a fix version!) applies not only to in-Parameters but also to out-Parameters. The result is that 5.1.1 cannot be applied for projects having
application/octet-stream
as response parameters. It is not only a breaking change (requiring source code change) the results in compile errors, these errors cannot be fixed, asMultipartFile
is not a valid return value.After the Change the generated API is this:
Before Version 5.1.1 it was:
However, the newly generated interface contract cannot be satisfied in a clean way, as
MultipartFile
is not supposed to be a return value. See Spring documentation ofMultipartFile
openapi-generator version
5.1.1
OpenAPI declaration file content or url
Generation Details
Generation with
openapi-generator-maven-plugin
Steps to reproduce
See compile errors in the following PR https://github.com/DiPA-Projekt/dipa-hub/pull/300
Related issues/PRs
Introduced in #9331
Suggest a fix
Ensure that #9331 is only applied to in parameters and not to response parameters.