Openapi-generator: [JAVA] Untyped request bodies not handled

[tsiq-karold]

Description

Generating code (both client and server) for a model where a resource has a body parameter with either no type or of type object generates a warning and code which does not compile.

Warning this generates is similar to:

[main] WARN  o.o.codegen.DefaultCodegen - Unknown type found in the schema: object
[main] WARN  o.o.codegen.DefaultCodegen - The following schema has undefined (null) baseType. It could be due to form parameter defined in OpenAPI v2 spec with incorrect consumes. A correct 'consumes' for form parameters should be 'application/x-www-form-urlencoded' or 'multipart/form-data'
[main] WARN  o.o.codegen.DefaultCodegen - schema: class ObjectSchema {
    class Schema {
        title: null
        multipleOf: null
        maximum: null
        exclusiveMaximum: null
        minimum: null
        exclusiveMinimum: null
        maxLength: null
        minLength: null
        pattern: null
        maxItems: null
        minItems: null
        uniqueItems: null
        maxProperties: null
        minProperties: null
        required: null
        type: null
        not: null
        properties: null
        additionalProperties: null
        description: null
        format: null
        $ref: null
        nullable: null
        readOnly: null
        writeOnly: null
        example: null
        externalDocs: null
        deprecated: null
        discriminator: null
        xml: null
    }
    type: object
    defaultObject: null
}
[main] WARN  o.o.codegen.DefaultCodegen - codegenModel is null. Default to UNKNOWN_BASE_TYPE

Generated client code in DefaultApi:

import org.openapitools.client.model.UNKNOWN_BASE_TYPE;

...

public void thePost(UNKNOWN_BASE_TYPE UNKNOWN_BASE_TYPE) throws ApiException {

    thePostWithHttpInfo(UNKNOWN_BASE_TYPE);
}

No such model is generated though even if it was, it wouldn't be terribly useful. The server generated code has a very similar problem.

I have tried this with both type: object and no type specified.

openapi-generator version

I've tried with 3.3.2 and master.

OpenAPI declaration file content or url

{
  "swagger": "2.0",
  "info": {
    "version": "0.0.1",
    "title": "Test"
  },
  "basePath": "/",
  "paths": {
    "/": {
      "post": {
        "operationId": "thePost",
        "parameters": [
          {
            "in": "body",
            "name": "body",
            "required": "false",
            "schema": {
                "type": "object"
            }
          }
        ],
        "responses": {
          "200": {
            "description": "response"
          }
        }
      }
    }
  }
}

Command line used for generation

Client generation:
java -jar ~/.m2/repository/org/openapitools/openapi-generator-cli/3.3.2/openapi-generator-cli-3.3.2.jar generate -c config.json -i api.json -g java -o output

The contents of config.json are:

{
  "library": "jersey2"
}

Having said that, I have tried with other libraries and the same problem exists.

Server generation:
java -jar ~/.m2/repository/org/openapitools/openapi-generator-cli/3.3.2/openapi-generator-cli-3.3.2.jar generate -i api.json -g jaxrs-jersey -o output

Steps to reproduce

Generate code with the model above and compile.

Related issues/PRs

This looks similar to https://github.com/OpenAPITools/openapi-generator/pull/1078 but the proposed fix in that PR doesn't resolve this particular problem.

Suggest a fix/enhancement

I have been able to fix this by changing https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/java/org/openapitools/codegen/DefaultCodegen.java#L4556 to set codegenModelName to typeMapping.get("Object") instead of the hardcoded UNKNOWN_BASE_TYPE. I'm not totally convinced that's the right fix though but if it is I'm happy to open a PR with that.

[wing328]

@tsiq-karold thanks for reporting the issue. I plan to add better handling of free-form object via #1338. It may not completely fix the problem you reported but should be getting closing to a solution.

[tsiq-karold]

Thanks @wing328, I'll watch #1338 for now then and will come back to this issue once that's in.

[tsiq-karold]

Hi @wing328, now that #1338 is in, can we discuss this issue again please?

[samuelAle]

The fix is published in v4.0.0-beta

Not sure what the timeline is for 4.0.0, but it would be nice to get this in the next stable release

[janschj]

4.0.0-beta has not solved oneOf if used in a requestBody. Requestbody is generated as UNKNOWN_BASE_TYPE. swagger codegen atleast translate to Object.

[tsiq-karold]

@samuelAle I can confirm that this fixes the problem in my case. Would be great to get it into a release soon.

[fjs018]

Hello, I am using 4.0.0-beta2 (generating a spring server) and I'm seeing the same issue as the comment from @janschj from January 5th. The requestBody is generated with UNKNOWN_BASE_TYPE when oneOf is used in the requestBody.

[Nabarun]

I am also seeing the same issue in Post request body. Is someone looking at this issue?

[artonge]

Same here with 4.0.0-beta3

[Emdee89]

Facing the same issue with 4.0.0-beta3.

[mrbatista]

Same problem if define two endpoints with formData property (same name). Example with relevant code:

openapi: 3.0.0
paths:
  "/path1:
    post:
      tags:
        - Model
      operationId: Model_create
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
            format: JSON
      requestBody:
        $ref: "#/components/requestBodies/Model_create"
      responses:
        "204":
          description: Request was successful
      deprecated: false
  "/path2":
    post:
      tags:
        - Model_update
      operationId: Model_update
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
            format: JSON
        - name: fk
          in: path
          required: true
          schema:
            type: string
      requestBody:
        $ref: "#/components/requestBodies/Model_create"
      responses:
        "204":
          description: Request was successful
      deprecated: false
components:
  requestBodies:
    Model_create:
      content:
        multipart/form-data:
          schema:
            type: object
            properties:
              file:
                description: File to upload
                type: string
                format: binary
            required:
              - file

[JFCote]

I confirm what @mrbatista is saying. I have a spec to reproduce that looks almost identical to his so I will not copy it.
@wing328 Is there a PR somewhere to address this problem? It is blocking me to move to OpenApi V3 (because OpenApi V2 doesn't have this problem).

[wing328]

@wing328 Is there a PR somewhere to address this problem?

I don't think anyone has opened one yet.

[wing328]

I'm able to workaround the issue using $ref in the multipart/form-data as follows:

openapi: 3.0.0
info:
  description: >-
    This is a sample server Petstore server. For this sample, you can use the api key
    `special-key` to test the authorization filters.
  version: 1.0.0
  title: OpenAPI Petstore
  license:
    name: Apache-2.0
    url: 'http://www.apache.org/licenses/LICENSE-2.0.html'
paths:
  "/path1":
    post:
      tags:
        - Model
      operationId: Model_create
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
            format: JSON
      requestBody:
        $ref: "#/components/requestBodies/Model_create"
      responses:
        "204":
          description: Request was successful
      deprecated: false
  "/path2":
    post:
      tags:
        - Model_update
      operationId: Model_update
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
            format: JSON
        - name: fk
          in: path
          required: true
          schema:
            type: string
      requestBody:
        $ref: "#/components/requestBodies/Model_create"
      responses:
        "204":
          description: Request was successful
      deprecated: false
components:
  requestBodies:
    Model_create:
      content:
        multipart/form-data:
          schema:
            $ref: "#/components/schemas/form_object"
  schemas:
    form_object:
      type: object
      properties:
        file:
          description: File to upload
          type: string
          format: binary
      required:
        - file

(the issue has nothing to do with multiple endpoints as I could repeat the issue with just the path1 endpoint)

We need to fix the issue in the InlineModelResolver.java to flatten the inline schemas defined in content

If anyone wants to give it a try, please feel free to do so.

Otherwise, I'll take another look in Oct ...

[JFCote]

@wing328 Yes it fixes the error but it seems the code now think form_object (in your example) is a bodyParam instead of a formParam.

When I generate the server in Play Framework. I get this:

@ApiAction
public Result importStores(Long brandId) throws Exception {
    JsonNode nodeformObject = request().body().asJson();

Instead of expected:

@ApiAction
public Result importStores(Long brandId) throws Exception {
    Http.MultipartFormData.FilePart fileToUpload = request().body().asMultipartFormData().getFile("file-to-upload");

Somewhere in this new code to handle V3, we lose the concept of FormParam.

[wing328]

Declaring inline (as a workaround) should work, e.g.

      requestBody:
        content:
          application/x-www-form-urlencoded:
            schema:
              type: object
              properties:
                name:
                  description: Updated name of the pet
                  type: string
                status:
                  description: Updated status of the pet
                  type: string

https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/test/resources/3_0/petstore.yaml#L190-L201

[JFCote]

Will give it a try today. Thanks @wing328

[wing328]

Yes, please.

(I agree the generator should better handle references to content)

[JFCote]

Yes it work, I have been able to get around the bug. Thanks.