Fails to resolve correct path/filename for extended $ref

[daniellubovich]

I recently ran into an issue testing some of my more complex schema documents where combination schema $refs cannot be resolved properly if they are part of an "extended" $ref. It is a little hard to explain the case, but I think I have found a simple enough schema that causes the problem to occur.

// base.json
{
  "type": "object",
  "properties": {
    "some_value": { "$ref": "defs.json#/definitions/astring" }
  }
}

//

{
  "definitions": {
    "astring": {
      "description": "astring",
      "$ref": "defs2.json#/definitions/bstring"
    }
  }
}


// defs2.json
{
  "definitions": {
    "bstring": {
      "oneOf": [
        {
          "$ref": "#/definitions/cstring"
        },
        {
          "$ref": "#/definitions/dstring"
        }
      ]
    },
    "cstring": {
      "type": "string"
    },
    "dstring": {
      "type": "number"
    }
  }
}

The error that I see when trying to resolve this looks like:
Error while processing route: dynamic-form Token "cstring" does not exist. MissingPointerError: Token "cstring" does not exist.

This only seems to happen when the intermediate schema object is an "extended" ref. For example, if we remove the description from astring then we are able to dereference without issue. From doing some debugging it looks to me like our issue is that when resolving cstring, the path we resolve is defs.json#/definitions/cstring instead of looking in defs2.json. I think this is because when we resolve extended $refs, we explicitly do not update the pointer's path.

For reference:

json-schema-ref-parser/lib/pointer.js

Lines 240 to 245 in 13b0092

	if ($Ref.isExtended$Ref(pointer.value)) {
	// This JSON reference "extends" the resolved value, rather than simply pointing to it.
	// So the resolved path does NOT change. Just the value does.
	pointer.value = $Ref.dereference(pointer.value, resolved.value);
	return false;
	}

I would like to propose a fix, but feel ill-equipped to do so without some guidance. It does seem like updating the path in the above code fixes my specific issue, but clearly that decision was made for a reason so I'd rather not step on any toes without understanding the intent. Any thoughts would be greatly appreciated!

[daniellubovich]

I should also mention the issue described here: #168.

Based on the draft 07 spec, it seems like the behavior of objects with $ref and additional properties appears to be undefined. I think the decision on how to proceed with this behavior going forward may inform the decision made for this issue as well.

[karlvr]

This feels like the same problem that I've had, but I'm not sure what an extended ref is!

The problem I've had is that when it comes time to resolve (using your example):

    "bstring": {
      "oneOf": [
        {
          "$ref": "#/definitions/cstring"
        },
        {
          "$ref": "#/definitions/dstring"
        }
      ]
    },

... I've lost the context that these $refs are in defs2.json and it's just looking for #/definitions/cstring in my main document.

So I've patched resolve-external.js to "correct" refs as we crawl the external document so that they reference the external document.

I'm still testing this myself, but it seems promising. Here's the patch if it sounds like it might address this issue for you.

diff --git a/node_modules/@apidevtools/json-schema-ref-parser/lib/resolve-external.js b/node_modules/@apidevtools/json-schema-ref-parser/lib/resolve-external.js
index c7238fb..d1f1824 100644
--- a/node_modules/@apidevtools/json-schema-ref-parser/lib/resolve-external.js
+++ b/node_modules/@apidevtools/json-schema-ref-parser/lib/resolve-external.js
@@ -51,7 +51,7 @@ function resolveExternal (parser, options) {
  * If any of the JSON references point to files that contain additional JSON references,
  * then the corresponding promise will internally reference an array of promises.
  */
-function crawl (obj, path, $refs, options) {
+function crawl (obj, path, $refs, options, external) {
   let promises = [];
 
   if (obj && typeof obj === "object" && !ArrayBuffer.isView(obj)) {
@@ -59,16 +59,17 @@ function crawl (obj, path, $refs, options) {
       promises.push(resolve$Ref(obj, path, $refs, options));
     }
     else {
+      if (external && $Ref.is$Ref(obj)) {
+        /* Correct the reference in the external document so we can resolve it */
+        let withoutHash = url.stripHash(path);
+        obj.$ref = withoutHash + obj.$ref;
+      }
+
       for (let key of Object.keys(obj)) {
         let keyPath = Pointer.join(path, key);
         let value = obj[key];
         
-        if ($Ref.isExternal$Ref(value)) {
-          promises.push(resolve$Ref(value, keyPath, $refs, options));
-        }
-        else {
-          promises = promises.concat(crawl(value, keyPath, $refs, options));
-        }
+        promises = promises.concat(crawl(value, keyPath, $refs, options, external));
       }
     }
   }
@@ -107,7 +108,7 @@ async function resolve$Ref ($ref, path, $refs, options) {
 
     // Crawl the parsed value
     // console.log('Resolving $ref pointers in %s', withoutHash);
-    let promises = crawl(result, withoutHash + "#", $refs, options);
+    let promises = crawl(result, withoutHash + "#", $refs, options, true);
 
     return Promise.all(promises);
   }

[ajcool2k]

@daniellubovich Thanks for reporting this. I almost gave up until I saw the issue you created.

I believe I run into the same issue here. Went with a workaround nesting the $ref inside an oneOf to keep the description. Not sure if there's a better way but it fixes the resolving issues I run into.

{
    "parameters": {
        "description": "My parameter description ...",
        "oneOf": [
            {
                "$ref": "./external.schema.json#/definitions/ParameterDefinition"
            }
        ]
    }
}

[btruhand]

@daniellubovich if I get the problem correctly, it seems to be a case of nested references to external files? That is:

main file --- references ---> external file 1 --- references ---> external file 2

At least this seems to be the issue that I'm getting and guessing that this is the underlying problem.

I'm in a similar position where I'd be happy to help but would appreciate some guidance on it. From my perspective it seems there is at least a need to be able to propagate referencing context such that at the time of dereferencing the correct value can be obtained from the correct reference location

[karlvr]

@btruhand if you get a moment, your issue sounds like the issue that I've resolved. I've published a version of json-schema-ref-parser as @openapi-generator-plus/json-schema-ref-parser if you'd like to test it to see if it resolves your problem?

[btruhand]

@karlvr just got back to replying on this. I actually realized my problem is elsewhere (at least for the case that I was testing). Though I'll try to give your solution a whirl and see how it goes and get back with results for future reference

[benjamin-mogensen]

@karlvr where can I find your published package? I am facing an issue where json-schema-ref-parser creates references that are not supported by AJV and AJV can therefore not resolve them (see issue reported here). This is a huge problem for me because the schemas are really larger and I don't want to have to "hardcode" some replacement paths to have it AJV compliant (although at the moment that is my only choice).

[karlvr]

@benjamin-mogensen Right, hopefully it resolves the issue. I published it https://www.npmjs.com/package/@openapi-generator-plus/json-schema-ref-parser for interoperability with my https://www.npmjs.com/package/openapi-generator-plus. The source code is https://github.com/karlvr/json-schema-ref-parser. The master branch contains what's published to npm. I've also recently fixed the bundle task as well as I'm using that to convert schemas referencing external files into a single self-contained schema for use with tools that don't seem to support external references.

(I've fixed the reference to where I'd published it above; I was publishing a few things at the time!)

[benjamin-mogensen]

Thanks a lot for getting back on this. I tried using your package, bundled the schemas and then checked if the $ref -> $ref problem had been fixed. Unfortunately not so AJV still cannot compile the bundled schemas and I am forced to hard code a fix that replaces these "broken" paths in the $ref so that AJV can compile without errors.

[karlvr]

@benjamin-mogensen interesting; can you post an example file that it doesn't fix? My use case is resolved but I'm happy to look if this is related to what I've fixed.

[benjamin-mogensen]

@karlvr thanks for your reply - The schemas I bundle are very big and takes many $ref which in turn has many other $ref so it is a bit difficult to make a simple example. I will see if I can one of the coming days though. The result I get (in a super stripped down version) is like the link I posted above. But I guess the end result will not help us much finding out if we can fix this in json-schema-ref-parser :)

[y0n3r]

I am having this same issue. It's disappointing that it's still causing problems. If I have a $ref pointer that shows up after a "extended" $ref, as OP calls it, then the file can't be found.

CampaignResponse:
  allOf:
    - $ref: './Campaign.yml' # works just fine, no problem
      required:
        - id
        - state
        - candidates
      properties:
        id:
          type: string
        state:
          type: string
        revision:
          type: number
        publishedBy:
          $ref: './ChangeLogEntry.yml' # ERROR! Can't find file! (even though it DEFINITELY exists in the specified location)
        candidates:
          type: array
          items:
            $ref: './Candidate.yml'

As I'm sure you're all aware, this is incredibly frustrating because it's forcing me to have to duplicate data structures in multiple places just to get it to work properly. It shouldn't have to be this way. All explicit references should simply work. Any suggestions/comments/hacks would be warmly welcomed and greatly appreciated 🙏🏾

[philsturgeon]

@y0n3r this isn't a simple thing, and lets not just stamp our feet and talk about being disappointed. All time spent on this is entirely voluntary, and I already run a reforestation charity with about 40 hours of my free time each week, so sometimes issues dont get seen to as fast as we'd all like.

@karlvr thank you for submitting a pull request, I'll talk to you over there about getting it moving.

Everyone else, if you're seeing this issue, please give https://www.npmjs.com/package/@openapi-generator-plus/json-schema-ref-parser a try and see if it fixes that issue. We'll get the changes merged upstream ASAP.