invalid $ref object referenced with a type of %!s(<nil>)

[rodriguise]

I am exporting my spec from SwaggerHub and am getting this error at start:

invalid $ref object referenced with a type of %!s(<nil>)

My API is sensitive, but I can share it privately if necessary.

Thanks

[darrenmcc]

Hi rodriguise, might you be referencing an object that doesn't exist?

[rodriguise]

I can take this same file, which I do, and pass it both to go-swagger and AWS, which very picky and they have no trouble with it.

The swagger editor and linter show no issues with the file.

So no I’m not referencing something that doesn’t exist.

[jprobinson]

Howdy @rodriguise! Sorry for the delay, I've been on a bit of a vacation.

From looking at the code around this error, it looks like the tool may be having issues parsing a referenced type.

Do you have anything in your definitions section that does not have a type specified?

If not that, does your spec have any external references to other spec files?

[rodriguise]

I don’t. Is the ‘allOf’ property not supported, i.e. polymorphism?

…

On Oct 30, 2017, at 1:07 PM, JP Robinson ***@***.***> wrote: Howdy @rodriguise <https://github.com/rodriguise>! Sorry for the delay, I've been on a bit of a vacation. From looking at the code around this error, it looks like the tool may be having issues parsing a referenced type. Do you have anything in your definitions section that does not have a type specified? If not that, does your spec have any external references to other spec files? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#40 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC9vZ9GqFkv_5tProxec-KXq053GuThzks5sxiyJgaJpZM4QDNY7>.

[jprobinson]

That's it! At the moment, polymorphism is not supported.

We can probably add support for allOf by converting it to proto3's oneof. Would that be an acceptable conversion for your use case?

[niharkawli]

I am getting the same error too. Does it not work if we dont specify a type?
eg.
profile:
$ref: '#/definitions/Profile'

Is there any workaround for the same?

[jprobinson]

Hi @niharkawli, sorry for the delay.

At the moment, yes, you need to specify a type for every field. Would you prefer the tool to skip fields without types?

[jprobinson]

Sorry @niharkawli , I think I read your problem incorrectly. A $ref is allowed for local or external types. If you're still seeing a problem, mind sharing your yaml?

[optimality]

I'm having a similar problem with the Kubernetes API spec (2018/02/26 16:45:11 invalid $ref object referenced with a type of %!s(<nil>))

I went through and removed the fields with allOf and anyOf, and I still got the same failure, so I'm wondering if it's a different issue?

[jprobinson]

Hi @optimality. Sorry to hear you're running into issues, but without any more information about your swagger spec, I can't help you debug the issue.

You want to make sure any $ref values are in a responses, parameters or definitions block, there are no typos and any external references are valid.

[optimality]

@jprobinson Oh, it's the Kubernetes API spec.

[jprobinson]

Thanks! I wonder if the periods in the referenced names may be part of the issue. I'm plugging this into some tests and will get back to ya.

[jprobinson]

From what I can see, the k8s spec lacks the type field on all definitions. I'm trying to find documentation anywhere that says that field is not required but not finding much luck.

We could default the tool to assume type: object if none defined, but I'd prefer to find some documentation to support such a thing.

[optimality]

So, I'm pretty far from an expert on this, so take this with a grain of salt:

But my understanding is that none of the schema fields are required, it's just that the ones that are present apply constraints on which instances are valid. Omission of a constraint just implies that any instance is valid (according to that constraint).

I'm basing that on http://json-schema.org/latest/json-schema-validation.html#rfc.section.3.2:

Assertion keywords that are absent never restrict validation.

That suggests to me that the inferred "type" for the code generator should be "object."

[optimality]

Also, on the front page, there's this bit:

The most basic schema is a blank JSON object, which constrains nothing, allows anything, and describes nothing:

{}

You can apply constraints on an instance by adding validation keywords to the schema. For example, the “type” keyword can be used to restrict an instance to an object, array, string, number, boolean, or null:

{"type": "string"}

[jprobinson]

The recent rewrite (#81) has altered the error coming from the k8s spec, but we found the spec to be too much of an outlier from most APIs to to make 100% of the k8s use cases work for now.

New error:

╰─ openapi2proto -spec kubernetes.json                                                                                                                    
error: failed to transpile: failed to load OpenAPI spec: failed to resolve external references: failed to resolve object: failed to resolve map element for definitions: failed to resolve map element for io.k8s.apiextensions-apiserver.pkg.apis.apiextensions.v1beta1.JSONSchemaProps: failed to resolve map element for properties: '$ref' key contains non-string element (map[string]interface {})

The problem is still the same, though:

     "$ref": {
      "type": "string"
     },

Since the error message has changed and, I'm going to close this and create a new one to specifically look at this kind of reference.

[optimality]

I actually wound up writing a transpiler internally to just translate the Kube spec. It has a ton of edge cases that I don't think your code is set up to handle (and my code doesn't handle anything other than the Kube spec). I would suggest not focusing on it too much, it seems like it's a very special unicorn.

[jprobinson]

I've created an issue nonetheless: #82

If there are any other weirdo edge cases around reference in there, please feel free to add them in a comment, @optimality.