unexpected reference depth

[realCommitment]

Hi guys,

I am getting the following error

error generating code: error creating operation definitions: error generating response definitions: error turning reference (#/paths/~1me~1/put/responses/400) into a Go type: unexpected reference depth: 6 for ref: #/paths/~1me~1/put/responses/400 local: true

I see that there is a validation in the source code against strictly defined depth, but is there a specific reason for that?

[gakesson]

Hello, I'm also a bit curious to why this depth-restriction exists. I would appreciate some insights!

Best Regards,

[jabielecki]

This happens when using notation $ref: "./components/schemas/MyTypeName.yaml" in more than one place, but where the root yaml file is missing an (seemingly reduntant, yet crucial) entry:

components:
  schemas:
    MyTypeName:
      $ref: "./components/schemas/MyTypeName.yaml"

This is just one case, there might be other conditions triggering the same problem. Tested on v1.12.4.

[clarktlaugh]

I am running into this as well. I have a YAML OpenAPI definition that is referencing a component in a JSON file,

defs.yaml:

components:
   schemas:
      CategoryStoreRequest:
      type: object
      $ref: "../model/category.json"

and then, in ../model/category.json, there is:

{
    "type": "object",
    "title": "category",
    "properties": {
        "_id": {
            "type": "string",
            "description": "uniquely identifies the revision of the category",
            "pattern": "^[a-fA-F0-9]{24}$"
        },
        ...
        "attributes": {
            "$ref": "common.json#/$defs/attributes"
        }
    },
    "additionalProperties": false
}

and then in common.json, there is:

{
    "title": "common",
    "type": "object",
    "$defs": {
        "attributes": {
            "type": "array",
            "maxItems": 1,
            "items": {
                "$ref": "#/$defs/attribute"
            }

I am getting the error:

error generating code: error generating type definitions: error generating Go types for component schemas: error converting Schema CategoryStoreRequest to Go type: error generating Go schema for property 'attributes': error turning reference (common.json#/$defs/attributes) into a Go type: unexpected reference depth: 3 for ref: #/$defs/attributes local: false

and can't figure out what to do to fix it.

Any suggestions?

[t94j0]

I am getting this as well using the Censys API: https://search.censys.io/api/openapi.yml

[SchulzKilian]

I get the same error for this line: $ref: '#/components/schemas/Photo/properties/photoId'

Maybe it is because im nesting too much and should just directly recreate photoId?`

[paambaati]

Same error when generating for the Turso platform API at https://raw.githubusercontent.com/tursodatabase/turso-docs/main/api-reference/openapi.json

[clarkmcc]

I'm also having this issue when generating for the HP SDS API https://gist.github.com/clarkmcc/46d9e033c267c9017e4d1d5952e97ba2

error generating code: error creating operation definitions: error describing global parameters for POST//api/credentials/verifyCredentials: error generating type for param (deviceCredentialCollection): error turning reference (#/definitions/DeviceCredentialCollection) into a Go type: unexpected reference depth: 3 for ref: #/definitions/DeviceCredentialCollection local: true

[mromaszewicz]

This is because you are loading a Swagger 2.0 specification, which is different from OpenAPI 3.0. You'll need to convert it before using oapi-codegen on it.

[mromaszewicz]

Hi guys,

I am getting the following error

error generating code: error creating operation definitions: error generating response definitions: error turning reference (#/paths/~1me~1/put/responses/400) into a Go type: unexpected reference depth: 6 for ref: #/paths/~1me~1/put/responses/400 local: true

I see that there is a validation in the source code against strictly defined depth, but is there a specific reason for that?

Yes, because we assume OpenAPI 3.0 document structure, and any other depth would be invalid here.

[clarkmcc]

@mromaszewicz will do, thank you. It seems like a more helpful error message would be useful in this case to save you from having to deal with this kind of thing in the future :).

[mromaszewicz]

Oh, I agree, but here is my dilemma. Right now, I use kin-openapi's loader to load the spec. It performs things like relative reference resolution via URI when loaded directly from a URL or file.

In order to tell what it's loading, I would have to pre-emptively parse the file as unstructured YAML and look for a swagger or openapi property and determine the version from that. So far so good.

Now, when I call the loader again, it might fetch it again over the internet a second time. I realize this isn't a big inefficiency, but I don't know whether its better to fail subtly, or double-load specifications.

If I donwload a remote file to a local one in /tmp or something, than any relative references in there break.

[mromaszewicz]

I am getting this as well using the Censys API: https://search.censys.io/api/openapi.yml

This is an interesting one. x-partials isn't a standard top level key under components and it has an extra level of depth, so we don't know how to look into it.

Once the specification is parsed, any property keys which aren't part of the spec are discarded, so the whole components/x-partials section is invisible to use.

What you have is an invalid spec.