Bug: `panic: runtime error: invalid memory address or nil pointer dereference` Building Model about libopenapi HOT 8 CLOSED

looks like more crazy $ref issues. This is one horrible auto-generated spec.

For example:

$ref: "#/paths/~1architectures/get/responses/200/content/application~1xml;%20charset=utf-8/schema

from libopenapi.

Oh wow, I made it work, just needed a couple more tweaks to get the path right. New patch inbound!

from libopenapi.

Will investigate, thanks for finding!

from libopenapi.

Quick question, Has this spec ever worked? Have those references ever been picked up?

The more I look at this, the less sure I am there is a way to resolve it, that path is invalid and it cannot be found using JSONPath. The reason this is panicing (which I can fix) is that the JSON Path being generated from that component reference is currently invalid. This is the type of thing which is causing the panic

$.paths./architectures.get.responses.401.content.application/xml;%20charset=utf-8.['schema']

Should actually be:

$.paths./architectures.get.responses.401.content['application/xml;%20charset=utf-8']['schema']

However this path cannot be found. I've tried it against a few different tools to double check it's not the library that libopenapi is using under the hood. (https://github.com/vmware-labs/yaml-jsonpath). It's not.

When I load up the spec in my IDE, those references cannot be followed, they can't be looked up there either.

          content:
            application/xml; charset=utf-8:
              example:
                code: unknown_architecture
                summary: "Architecture does not exist: x999"
              schema:
                $ref: "#/paths/~1architectures/get/responses/401/content/application~1xml;%20charset=utf-8/schema"
          description: Not Found.

This is clearly auto-generated, but it's doing something I don't think I can fix, the path simply isn't reachable, so whilst this spec has valid syntax, it's not actually valid because those paths cannot be looked-up using code (at least, not the way I have been testing)

from libopenapi.

Yeah I just had a quick check with an older version of our tooling and it validates that it is not valid (can't resolve the ref as you say), the issues is definitely just that a panic is thrown in this case where it would be better to receive a usable error

from libopenapi.

I'm going to try a couple of other things to see if I can shoehorn in a lookup, but it's not looking great, I can't trick the library into finding those whacky paths, either way, I will implement some cleaner handling and prevent the panic.

from libopenapi.

This should be resolved in v0.4.4. Please confirm when convenient.

from libopenapi.

can confirm this is fixed

from libopenapi.