[BUG][Python] Wrong generated Type tree for Inline response schema

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• Have you tested with the latest master to confirm the issue still exists?
• Have you searched for related issues/PRs?
• What’s the actual output vs expected output?
• [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

I am trying to retrieve the data from a path using the Python-generated code from an openapi spec file. The python code generated returns a ApiTypeError. When investigating deeper, it seems the openapi spec file is not read correctly, or is missing some types in the inline type checking. Separately, the _check_return_type=False does not seem to work to skip this step.

openapi-generator version

Both 5.0.0 and 5.0.1 have been tried

OpenAPI declaration file content or url

{
  "swagger": "2.0",
  "info": {
    "title": "Quick Base API",
    "version": "1.0.0"
  },
  "host": "api.quickbase.com/v1",
  "paths": {
    "/fields/{fieldId}": {
      "parameters": [ ... ],
      "get": {
        "description": "Gets the properties of an individual field, based on field id.",
        "parameters": [ ... ],
        "responses": {
          "200": {
            "description": "Success",
            "schema": {
              "type": "object",
              "properties": {
                "id": { ... },
                "fieldType": { ... },
                "label": { ... },
                "properties": {
                  "description": "Additional properties for the field. ",
                  "type": "object",
                  "additionalProperties": true,
                  "properties": {
                    "comments": { ... },
                    "format": { ... },
                    "maxLength": { ... },
                    "allowNewChoices": { ... },
                    "displayAsLink": { ... },
                    "allowHTML": { ... },
                  }
                },
              }
            }
          }
        },
      },
    },
  },
}

Generation Details

java -jar openapi-generator-cli.jar generate -i oas.json -o quickbase-openapi-client -g python

Steps to reproduce

As above

Related issues/PRs

Checked, not found

Suggest a fix

In file: https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/PythonClientCodegen.java

In function: private String getTypeString(Schema p, String prefix, String suffix, List<String> referencedModelNames)

This seems to result with the above oas and generation into: fields_api.py

...
        self.get_field = Endpoint(
            settings={
                "response_type": ( {
                        str: ( {
                                str: (bool,date, datetime, dict, float, int, list, str, none_type, )
                            }, )
                    }, ),
                "auth": [],
                "endpoint_path": "/fields/{fieldId}",
                "operation_id": "get_field",
                "http_method": "GET",
                "servers": None,
            },
            params_map={
...

…But this returns a ApiTypeError: Invalid type for variable ‘id’. Required value type is dict and passed type was int at [‘received_data’][‘id’]

However, when the above is changed to:

        self.get_field = Endpoint(
            settings={
                "response_type": ( {
                        str: ( 
                            bool,date, datetime, dict, float, int, list, str, none_type,
                            {
                                str: (bool,date, datetime, dict, float, int, list, str, none_type, )
                            }, )
                    }, ),
                "auth": [],
                "endpoint_path": "/fields/{fieldId}",
                "operation_id": "get_field",
                "http_method": "GET",
                "servers": None,
            },
            params_map={
...

Then the code runs fine.

It seems as if the Response Types Tree does not resemble the json response schema very well.

Further (though this may be a seperate issue), passing _check_return_type=False, into kwargs, does not prevent Type checking to be conducted, this would otherwise have (to some degree) resolved this issue.

[uncleflo]

We have tried PHP, and that went without a hitch on the full OAS. We have not tried creating a working implementation with the PHP client, but surfacially it looks good (better and cleaner than python really). PHP still has the same inlineobject123 files, and it seems that the type checking is a simple ‘map[string,object]’ or a reference to a class ‘\OpenAPI\Client\Model\InlineResponse2004[]’.

In your above generated model:

self.get_field_properties = Endpoint(
            settings={
                'response_type': (InlineResponse200,),

It seems that in our generated python client code, wherever it is using classes for 'response_type', it works. But wherever it is using inline type tree definitions such as:

"response_type": ( {
                        str: ( {
                                str: (bool,date, datetime, dict, float, int, list, str, none_type, )
                            }, )
                    }, ),

It does not work, and should be fixed (apparently or in the direction of my issue description suggestions) in the java generation code.

With your ‘above v2 yaml spec’, what are you suggesting? That I use your process of generating yaml first, before generating the python client? This MAY work (have not tried this yet), but it occurs to me as not the ideal solution for anyone (the ideal solution being to fix the java generator for python code for inline type trees).

Adding refs to the extended original OAS file using a preprocessing script is also a potential solution we have thought of, but it requires constant monitoring that correct interpreteable names for the components are used. Again, if it’s not ideal for us, it hardly could be ideal for someone else.

At the moment, we are resolving our problem by manually editing the generated python client code, with the correct inline type tree, as I described in the issue description. I prefer this ticket to remain open until the issue is resolved (the generator not outputting correct inline type trees).

[spacether]

@polavishnu4444 please us the 6.2.0 openapi-generator with the python client. If you are still having this issue please post your spec here and point out which schema and payload are not working as expected.