[BUG] [Python] 6.1.x Import missing for models with string pattern

[jtvmatos]

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

After the last minor relase (6.1.0) the python sdk is broken when a component schema with a string pattern is provided as reference for a endpoint parameter. In this scenario, in the api files is a missing import for the openapi_types.

In practice, using the openapi spec yaml below, in the 6.0.1 version, even though the model/uuid_component.py file was created is not used, and the openapi_type in the api file is a string:

                'openapi_types': {
                    'pattern_value':
                        (str,),
                },

Hopwever, in the new release, 6.1.0, the openapi_type is now described as UuidComponent but there is no model import in the file:

                'openapi_types': {
                    'pattern_value':
                        (UuidComponent,),
                },

openapi-generator version

6.1.0

OpenAPI declaration file content or url

---
openapi: 3.0.3
info:
  title: Test pattern
  version: 0.0.0
servers:
- url: localhost
paths:
  /api/{pattern_value}:
    get:
      tags:
      - test1
      operationId: test1
      parameters:
      - name: pattern_value
        in: path
        required: true
        schema:
          $ref: '#/components/schemas/uuid_component'
      responses:
        "200":
          description: OK
          content:
            application/json:
              schema:
                type: string
components:
  schemas:
    uuid_component:
      pattern: "/[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}/"
      type: string

Generation Details

Python Language without additional configurations.

Steps to reproduce

Generate openapi 6.1.0 spec - python

Related issues/PRs

Suggest a fix

[jtvmatos]

hi @wing328,

I trackback this behavior to this commit: Fix parameter schema mapping (OpenAPITools/openapi-generator#12893 - OpenAPITools/openapi-generator@bdd54da)

Do you have any clue what could have caused this change?

thanks!

[spacether]

Not sure why that changed. If you use python-experimental it will work. As shown by this test which is passing in CI
https://github.com/OpenAPITools/openapi-generator/blob/62e28a27dd8e2326e3be3d8b991ae7361f6644f0/samples/openapi3/client/3_0_3_unit_test/python-experimental/test/test_paths/test_request_body_post_pattern_validation_request_body/test_post.py#L203

[jtvmatos]

Hi @spacether, thanks for the feedback.

However, I cannot use the python-experimental because our production python env is lower than 3.9. And now, because of this bug we can't update to the new version openapi either.

[spacether]

Sorry to hear that. What's the lowest python version that you need to support?

[jtvmatos]

Sorry to hear that. What's the lowest python version that you need to support?

python 3.7

[jtvmatos]

I was trying to make a test case to find what is wrong.
I believe that the "string enum", should have a equivalent behavior to the "string pattern".

  /fake/string/refs/{pattern}/{enum}:
    post:
      tags:
        - fake
      description: Test pattern and enum in parameters (ref)
      operationId: StringPattern
      parameters:
        - name: pattern
          in: path
          description: string pattern
          required: true
          schema:
            $ref: '#/components/schemas/StringPattern'
        - name: enum
          in: path
          description: string enum
          required: true
          schema:
            $ref: '#/components/schemas/StringEnum'
      responses:
        '200':
          description: Output schema
          content:
            application/json:
              schema:
                type: string

And:

    ParametersStringPattern:
      type: string
      pattern: '[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}'
    ParametersStringEnum:
      type: string
      enum:
        - "aaa"
        - "bbb"
        - "ccc"

But for this scenario the api file add the import for the ParametersStringEnum but not for the ParametersStringPattern. Moreover, the regex also appears in this api file (contrary to what happens for the enum, , in which the allowed_values only appear in the model file.

Apparently the string enums and string patterns are following different paths. 😕

[wing328]

@jtvmatos thanks for reporting the issue with the details. I'll take a look today.

[wing328]

Can you please PM me via Slack for a quick chat (IM) about this issue?

https://join.slack.com/t/openapi-generator/shared_invite/zt-12jxxd7p2-XUeQM~4pzsU9x~eGLQqX2g

[spacether]

@jtvmatos I just changed python-experimental so that it uses python >= 3.7
Want to give it a try?

[antssilva96]

Hi @spacether ! I just validated and the issue mentioned here regarding UUIDs seems to be working with the new release (that is using python-experimental)...

However, we're encountering a bug that had been previously fixed: #11 . When I fixed it I only did so in the Python generator, not on the PythonExperimental, so now that the Python Generator is the previously called PythonExperimental, the problem is back.

Additionally, there are a number of breaking changes from updating this minor:

• request body parameter in calls no longer uses the name of the request body in the spec but is body
• api resources are no longer in .api. but instead they are in .apis.tags.

which is breaking our python clients. Is there any breaking changes list will all the changes we should be aware of ?

Thanks!

[spacether]

Is there any breaking changes list will all the changes we should be aware of ?

The list of breaking changes that I know about is included in the migration guide
That migration guide includes the tags changes and others.

Any other breaking changes that exist are bugs, or features that exist in python-prior and not in python.

[spacether]

Closing this issue because the import issue is working in this repo.
The string regex issue is being tracked separately in: #11