[BUG] [Python] Wrong model when using dicts

[waterfallwhitebread]

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

Having a spec that should include a dict property it becomes a Optional[Any] type instead in the generated model. Using the same spec and just modifying the "openapi" attribute by changing it to "3.0.0" instead generated a model with type Dict[str, StrictStr] as expected.

Should be:

class MyConfigValue(BaseModel):
    """
    Some description.
    """ # noqa: E501
    myprop: Dict[str, StrictStr]
    __properties: ClassVar[List[str]] = ["myprop"]

    model_config = {
        "populate_by_name": True,
        "validate_assignment": True
    }

is

class MyConfigValue(BaseModel):
    """
    Some description.
    """ # noqa: E501
    myprop: Optional[Any]
    __properties: ClassVar[List[str]] = ["myprop"]

    model_config = {
        "populate_by_name": True,
        "validate_assignment": True
    }

openapi-generator version

7.1.0 (also tried snapshot of 7.2.0)

OpenAPI declaration file content or url

{
  "openapi": "3.1.0",
  "info": {
    "title": "MY.FANCY.API",
    "version": "0.1.0"
  },
  "servers": [
    {
      "url": "/",
      "description": "Local"
    }
  ],
  "paths": {
    "/config/get_config_value": {
      "post": {
        "tags": [
          "My Configurations"
        ],
        "summary": "Get Config Value",
        "description": "Some description.",
        "operationId": "get_config_value_config_get_config_value_post",
        "requestBody": {
          "content": {
            "application/json": {
              "schema": {
                "$ref": "#/components/schemas/GetMyConfigValueRequest"
              }
            }
          },
          "required": true
        },
        "responses": {
          "200": {
            "description": "Successful Response",
            "content": {
              "application/json": {
                "schema": {
                  "$ref": "#/components/schemas/MyConfigValue"
                }
              }
            }
          }
        }
      }
    }
  },
  "components": {
    "schemas": {
      "MyConfigValue": {
        "properties": {
          "myprop": {
            "additionalProperties": {
              "type": "string"
            },
            "type": "object",
            "title": "Myprop"
          }
        },
        "type": "object",
        "required": [
          "myprop"
        ],
        "title": "MyConfigValue",
        "description": "Some description."
      },
      "GetMyConfigValueRequest": {
        "properties": {
          "config_path": {
            "type": "string",
            "title": "Config Path"
          },
          "file_in_config": {
            "type": "string",
            "title": "File In Config"
          },
          "nested_keys": {
            "items": {
              "type": "string"
            },
            "type": "array",
            "title": "Nested Keys"
          }
        },
        "type": "object",
        "required": [
          "config_path",
          "file_in_config",
          "nested_keys"
        ],
        "title": "GetMyConfigValueRequest",
        "description": "Request to get a nested value from a config."
      }
    }
  }
}

Generation Details

npx @openapitools/openapi-generator-cli generate -i 'C:\xxx\my_api_openapi.json' -g python -o 'C:\xxx\python\dev\my_client' -p library=asyncio -p packageName=communication.my_rest_client --skip-validate-spec

Steps to reproduce

Just call the generator with provided spec

Related issues/PRs

Did not find any

Suggest a fix

[wing328]

"openapi": "3.1.0",

please fall back to 3.0.1 for the time being.

the issue seems to occur with python client generator only (while testing the spec with java confirms the output is good)

another interesting thing is if the additionalProperties' schema is integer instead of string. the doc will will display correctly (while the pydantic type is still incorrect)

[wing328]

FYI
@cbornet (2017/09) @tomplus (2018/10) @krjakbrjak (2023/02) @fa0311 (2023/10) @multani (2023/10)

[multani]

I tried to take a look at this issue.

I don't think it comes specifically from the Python generator:

• The Python generator generates the type (Dict / Any) based on the type of the CodegenProperty.

  In this part of the code generation:

  • With 3.0.0: cp.getIsMap() returns true and cp.getIsAnyType() returns false
  • With 3.1.0: cp.getIsMap() returns false and cp.getIsAnyType() returns true

  This explains why the Python code generator generates different types depending on the version.

• I tried to locate why the CodegenProperty is being filled with different values depending on the spec version:

  • I managed to locate this in the default "code generator".

    Depending on the version:

    • In 3.0.0: ModelUtils.isAnyType(schema) returns false because schema.getType() returns object
    • In 3.1.0: ModelUtils.isAnyType(schema) returns true because schema.getType() is null

This last part is outside of the OpenAPI Generator code base (it should be part of swagger-core, IIUC), I haven't debugged this further this point.

[wing328]

The reason why I think the issue is with the python generators is because I tested with java, csharp, ruby generators and the result is correct. You can try a few other generators as well.

I'll keep digging to see if I can find anything.

[wing328]

I think I found the issue. Will try to file a PR later this week.

[wing328]

I've filed java -jar modules/openapi-generator-cli/target/openapi-generator-cli.jar generate -g python -i /tmp/a.json -o /tmp/aaa199/
to fix the issue and local test result is good.