[DefaultCodegen] Possible missing model for request body for OAS 3.0

[Articus]

Description

Consider the following spec:

openapi: 3.0.0
info:
  title: Test
  version: 1.0.0
servers:
  - url: 'http://test/'
components:
  requestBodies:
    TestBodyInline:
      content:
        application/json:
          schema:
            type: object
            properties:
              test:
                type: string
paths:
  /test/ref/inline:
    post:
      summary: Test
      requestBody:
        $ref: '#/components/requestBodies/TestBodyInline'
      responses:
        '200':
          description: Success
          content:
            application/json:
              schema:
                type: string

For this spec CodegenOperation::bodyParam.dataType equals to "object" and no codegen model is generated for request body. A bit lost why this is happenning because 3 other possible scenarios (inline body + inline schema, inline body + ref schema, ref body + ref schema) work perfectly well.

[jmini]

I think that all generators are concerned by the issue. This should be improved at DefaultCodegen level.

The inline form is broken as well (tested with a java generator)

openapi: 3.0.0
info:
  title: Test
  version: 1.0.0
servers:
  - url: 'http://test/'
paths:
  /test/ref/inline:
    post:
      summary: Test
      requestBody:
        content:
          application/json:
            schema:
              type: object
              properties:
                test:
                  type: string
      responses:
        '200':
          description: Success
          content:
            application/json:
              schema:
                type: string

—

I have investigated a little bit, comparing these 2 cases (can be added to DefaultCodegenTest)

1. Petstore case:

@Test
public void testPetInRequestBody() {
	final OpenAPI openAPI = new OpenAPIParser().readLocation("src/test/resources/3_0/petstore.yaml", null, new ParseOptions()).getOpenAPI();
	final DefaultCodegen codegen = new DefaultCodegen();
	
	Operation operation = openAPI.getPaths().get("/pet").getPost();
	CodegenOperation co = codegen.fromOperation("/pet", "post", operation, openAPI.getComponents().getSchemas(), openAPI);
	
	Assert.assertEquals(co.bodyParam.dataType, “XXX”);
}

2. Case described in this issue ref_request_body.yaml is the content posted by @Articus:

@Test
public void testRefRequestBody() {
	final OpenAPI openAPI = new OpenAPIParser().readLocation("src/test/resources/3_0/ref_request_body.yaml", null, new ParseOptions()).getOpenAPI();
	final DefaultCodegen codegen = new DefaultCodegen();
	
	Operation operation = openAPI.getPaths().get("/test/ref/inline").getPost();
	CodegenOperation co = codegen.fromOperation("/test/ref/inline", "post", operation, openAPI.getComponents().getSchemas(), openAPI);
	
	Assert.assertEquals(co.bodyParam.dataType, “XXX”);
}

In the second case in the case where the name is null (which is the name of the referenced schema), then codegenModel is also null, and we goes in this branch with the warning "The folowing schema has undefined (null) baseType"... => https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/java/org/openapitools/codegen/DefaultCodegen.java#L4321

---

Our test suite is working because of the $ref at Schema level.

The current workaround is to write your spec like this:

openapi: 3.0.0
info:
  title: Test
  version: 1.0.0
servers:
  - url: 'http://test/'
components:
  schemas:
    SomeObject:
      type: object
      properties:
        test:
          type: string
          
paths:
  /test/ref/inline:
    post:
      summary: Test
      requestBody:
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/SomeObject'
      responses:
        '200':
          description: Success
          content:
            application/json:
              schema:
                type: string

[jmini]

Consider case reported by @macjohnny in #222 when solving this issue.

[macjohnny]

Consider case reported in #304, i.e. with OAS 2.0

[bjgill]

I've just independently re-discovered this in #659 (#99 and #231 look like more of the same).

This is a rather unfortunate regression from swagger-codegen. It is easy enough to work around, but a bit of a pain when trying to persuade other people to switch to openapi-generator.

From looking through the code, it seems as if the loss of InlineModelResolver as part of 5359776 (the initial commit adding openapi v3 support) may be responsible.

[jmini]

@bjgill thank you for the analysis, do you think you can propose a PR for this?