Unable to parse schema Errors

[jsciame]

Describe the bug
I'm attempting to convert a rather large open api schema to Pyhton bindings and am running across warnings that are dropping endpoints on the floor. I believe there is a couple of issues.

1. Refs not supported: Do you know if there are plans to add support for references in request body? I'll look at ways to flatten this schema out without references and try this again

"requestBody": {
                    "content": {
                        "application/json": {
                            "schema": {
                                "$ref": "#/components/schemas/MetadataFieldGroupType"
                            }
                        },
                        "application/xml": {
                            "schema": {
                                "$ref": "#/components/schemas/MetadataFieldGroupType"
                            }
                        }
                    },
                    "required": true,
                    "description": ""
                }

WARNING` parsing PUT /collection within collection. Endpoint will not be generated.
Could not find reference in parsed models or enums

Reference(ref='#/components/schemas/ItemSearchType')
WARNING parsing POST /collection within collection. Endpoint will not be generated.

Could not find reference in parsed models or enums
Reference(ref='#/components/schemas/CollectionType')

2. Parth parameters not match with path. I believe this may be due to the open "in path" vs "in query" issue.

WARNING parsing GET /collection/{collection-id}/item within collection. Endpoint will not be generated.

Incorrect path templating for /collection/{collection-id}/item (Path parameters do not match with path)

{
                        "required": true,
                        "schema": {
                            "type": "string"
                        },
                        "in": "path",
                        "name": "collection-id",
                        "description": "The collection id."
                    }

3. Generic cannot parse parameter of endpoint getAccessGraphDot

cannot parse parameter of endpoint getAccessGraphDot

Schema(title=None, multipleOf=None, maximum=None, exclusiveMaximum=None, minimum=None, exclusiveMinimum=None, maxLength=None, minLength=None, pattern=None, maxItems=None, minItems=None, uniqueItems=None, maxProperties=None, minProperties=None, required=None, enum=['ancestor', 'grant'], type=<DataType.STRING: 'string'>, allOf=[], oneOf=[], anyOf=[], schema_not=None, items=None, properties=None, additionalProperties=None, description=None, schema_format=None, default=None, nullable=False, discriminator=None, readOnly=None, writeOnly=None, xml=None, externalDocs=None, example=None, deprecated=None)

To Reproduce
Steps to reproduce the behavior:

1. Run openapi-python-client generate --path openapi/spec.json
2. Run openapi-python-client generate --path openapi/spec.yaml

Expected behavior
A full python client should be generated without warnings.

OpenAPI Spec File
Standby. Making sure I have approval to share this schema since its coming from a 3rd party vendor.

Desktop (please complete the following information):

• OS: macOS 12.4
• Python Version: 3.8.9
• openapi-python-client version: 0.11.4

[dbanty]

Refs not supported: Do you know if there are plans to add support for references in request body? I'll look at ways to flatten this schema out without references and try this again

I think all references of the form #/components/schemas/ should already be supported. There are other types of references that aren't, but schemas should be. That error could be due to missing references or references that, themselves could not be generated for some reason. The most common reason is that circular and recursive references are not supported.

[bakkiaraj]

I do confirm that, refs are supported. Ex: from https://codebeamer.com/cb/api-docs/v3.json

 "requestBody": {
          "content": {
            "application/json": {
              "schema": {
                "$ref": "#/components/schemas/ExportProject"
              }
            }
          }
        },

The above is fully supported and generated python code is working.

[Southclaws]

I'm running into this for schema refs using this spec: https://github.com/Southclaws/storyden/blob/main/api/openapi.yaml

It seems even schema refs don't work for me currently on 0.21.2 perhaps heavily nested refs are the issue?

[eli-bl]

@Southclaws:

I'm running into this for schema refs using this spec: https://github.com/Southclaws/storyden/blob/main/api/openapi.yaml
It seems even schema refs don't work for me currently on 0.21.2 perhaps heavily nested refs are the issue?

There are some known issues with allOf, regardless of whether you're using many levels of refs or not.

One that I suspect is applicable in your case is #1091, because PostProps is derived from two types including PostMetadata, and PostMetadata is derived from another type with no changes at all (i.e. it's just an alias for CommonProperties). That is legal in OpenAPI, but the generator currently can't handle it, and unfortunately the error message is not helpful (it just acts as if it can't resolve the reference to PostMetadata).

Another one that I think might affect your spec is #1090, because you're defining createdAt in CommonProperties and then overriding it in PublicProfile with slightly different attributes. Again, I believe that's legal but the generator doesn't like it. I would expect you to see an error like "Properties has conflicting values" in that case, but it might be masked by the other errors.

[Southclaws]

Ah that makes sense, I actually didn't know that prop was being overridden either so I'll take a look at that (it may be legal but it doesn't feel like a good thing!) the main use-case for my usage of allOf with a single item is generating invariant types with unique names in Go, but I can probably remove that for this particular case anyway.

Thanks for looking into it!

[eli-bl]

@Southclaws Btw, it looks like the latest release already has the fix for #1091 - and the other bug has a PR up that might get merged soonish.

[Anarcroth]

Still running into this issue, where the request body is not able to handle the schema.$ref. Adding/changing the ref with allOf, anyOf, oneOf doesn't seem to help.