[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?

[bjgill]

I've started having a look at restoring InlineModelResolver.java - see https://github.com/bjgill/openapi-generator/tree/InlineModelResolver.

I'm now out of time to work on this for now, however. Anyone else who wants to pick this up would be more than welcome.

[antihax]

I've also started digging through this and trying to resolve the changed function names. Are you actively working on this also? @bjgill

[bjgill]

No - I started work in https://github.com/bjgill/openapi-generator/tree/InlineModelResolver, but am not going to have time to work on this for the foreseeable future. I'd be very happy to let you handle this.

[bjgill]

OK - the following (v2) definition was fixed by #736 (thanks @antihax!):

  ObjectOfObjects:
    description: An object of objects
    type: object
    properties:
      foo:
        type: object
        properties:
          bar:
            type: string

However, the following still doesn't seem to work (at least for rust-server):

  ArrayOfObjects:
    description: An array of objects
    type: array
    items:
      properties:
        filename:
          description: A non-required property
          type: string
        contents:
          description: A required property
          type: string
      required:
      - contents
      type: object

[jmini]

@bjgill:

I think support for items in array is exactly targeted by this test:

openapi-generator/modules/openapi-generator/src/test/java/org/openapitools/codegen/InlineModelResolverTest.java

Lines 279 to 303 in e7340bf

	/*
	@Test
	public void resolveInlineArraySchemaWithTitle() throws Exception {
	OpenAPI openapi = new OpenAPI();
	openapi.getComponents().addSchemas("User", new ArraySchema()
	.items(new ObjectSchema()
	.title("InnerUserTitle")
	.access("access")
	.readOnly(false)
	.required(true)
	.description("description")
	.name("name")
	.addProperties("street", new StringSchema())
	.addProperties("city", new StringSchema())));
	new InlineModelResolver().flatten(openapi);
	Schema model = openapi.getComponents().getSchemas().get("User");
	assertTrue(model instanceof ArraySchema);
	Schema user = openapi.getComponents().getSchemas().get("InnerUserTitle");
	assertNotNull(user);
	assertEquals("description", user.getDescription());
	}

(and the next ones)

[adamdecaf]

I'm pretty sure the Go generator has the same problem (#1112). Is there something I can do to to help that generator? It sounds like a DefaultCodegen fix?

I've got an OpenAPI v3 spec, not v2 like mentioned in #8 (comment)

[adamdecaf]

I figured out my problem. It was missing components.schemas for a components.requestBodies.

https://github.com/moov-io/api/pull/43 was the fix for my project

[ceefour]

I just hit by this. still happened on 4.0.0.beta.

[cbtum]

I am trying to use open api generator 5 to generate a client based on the jira cloud specification. Unfortunately, the request body model for doTransition (#/components/schemas/IssueUpdateDetails) is always missing, even though it is specified as described by #8 (comment). Any ideas what I might be missing? Is there any special configuration required?

[wtrocki]

I think this issue have been solved (based on specified schema).