How to map object from resolved doc back to $ref in original unresolved doc

[padamstx]

Hi,
I'm writing a custom rule function that needs to examine the schemas within the resolved version of an openapi definition. This function needs to compare two schema properties p1 and p2 to determine if they are in fact the same schema. In this context, p1 and p2 are like-named schema properties from two different schemas. If p1 and p2 represent primitive types, the comparison is straightforward. However, if p1 and p2 are object schemas (i.e nested objects), then they are
"equivalent" only if they were defined with the same $ref in the original unresolved API definition.

Is there a reliable way to map an object (perhaps based on its jsonpath) back to it's original form in the original/unresolved API definition?

Thanks in advance for any help.
Phil

[magicmatatjahu]

Hi! Have you tried comparing two objects using the === operator. Ref Resolver should resolve the same refs to the same object in memory, so references to both objects should point to the same memory registry.

Also in my logic, I would need information about a potential refs in a particular resolved path and would like to know from maintainers if this is possible.

[padamstx]

Yes, I also assumed that the resolver would simply replace all $refs to a particular object with a single instance of the referenced object, but that doesn't seem to be the case as === didn't work even when both objects were originally defined with the same $ref in the unresolved schema.

[padamstx]

I initially tried to use the documentInventory field within the context object that's passed to each rule, but was not able to get that to work. Instead, I wrote some code that will accept a path to an object within the resolved spec, and then traverse the unresolved spec one path segment at a time. After taking each (single) step, if we're currently at a node that has a $ref, I switch the current cursor to that referenced object within the unresolved spec, then continue the traversal. It's not foolproof because it doesn't handle external refs (at least not yet, but that would likely require the use of the documentInventory field of the context object. But it seems to work fine for internal refs.
For those situations where I can't find the object within the unresolved spec, I back off and use a heuristic for the checks I'm performing.

While I've solved this for the most common scenarios for now, it would be really really nice if the spectral team was able to provide a utility function that performs this mapping such that it uses the documentInventory contained in the context and supports external refs as well.