Error when resolving nested schema refs by id ({"$ref": "#foo"})

[SleepWalker]

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure it has not already been reported

Fastify version

3.20.2

Plugin version

No response

Node.js version

v14.16.0

Operating system

Linux

Operating system version (i.e. 20.04, 11.3, 10)

Ubuntu 20.04.2

Description

refFinder fails to find a $ref by $id (docs), when the schema is nested, e.g.:

{
  "title": "Example Schema",
  "type": "object",
  "properties": {
    "nested": {
      "type": "object",
      "properties": {
        "firstName": {
          "$ref": "#foo"
        },
        "lastName": {
          "$ref": "#foo"
        }
      }
    }
  },
  "definitions": {
    "foo": {
      "$id": "#foo",
      "type": "string"
    }
  }
}

There are actually two errors (source):

• if there is no externalSchema, you'll get TypeError: Cannot convert undefined or null to object when executing for (var key of Object.keys(externalSchema)) {
• if externalSchema is specified, refFinder will fail to dereference $ref and a property will end up resolved to undefined which will trigger TypeError: Cannot read property 'type' of undefined on the later stages in buildCode

Looks like refFinder should look up for definitions starting from root instead of schema in the same way as it done for processing of #/definitions/foo refs.

Steps to Reproduce

const fastJson = require('fast-json-stringify');
const stringify = fastJson({
  title: 'Example Schema',
  type: 'object',
  properties: {
    firstName: { $ref: '#foo' },
    lastName: { $ref: '#foo' },
    nested: {
      type: 'object',
      properties: {
        firstName: { $ref: '#foo' },
        lastName: { $ref: '#foo' },
      },
    },
  },
  definitions: {
    foo: {
      $id: '#foo',
      type: 'string',
    },
  },
});

console.log(
  stringify({
    firstName: 'Matteo',
    lastName: 'Collina',
    nested: {
      firstName: 'Matteo',
      lastName: 'Collina',
    },
  }),
);

Expected Behavior

The nested $ref should be resolved. Here is an example of schema validation: https://www.jsonschemavalidator.net/s/sMCUkqfP

[mcollina]

Would you like to send a Pull Request to address this issue? Remember to add unit tests.

[Eomm]

Note that we must follow the Draft 07 spec

Your example has a fragment $id, so a root $id is needed (or we should apply the default as explained in the spec).

[SleepWalker]

@Eomm I can not get whether it is valid to use definitions deeper in scheme (see #/properties/nested/definitions).

{
  "properties": {
    "nested": {
      "type": "object",
      "properties": {
        "firstName": {
          "$ref": "#foo"
        },
        "lastName": {
          "$ref": "#bar"
        }
      },
      "definitions": {
        "bar": {
          "$id": "#bar",
          "type": "number"
        }
      }
    }
  },
  "definitions": {
    "foo": {
      "$id": "#foo",
      "type": "string"
    }
  }
}

This validator does not allow such usage, but this allows

The spec does not state where it is allowed to put definitions

---

Another one thing is that theoretically I can define a new subschema everywhere by just adding an $id to it:

{
  "properties": {
    "nested": {
      "$id": "nested",
      "type": "object",
      "properties": {
        "firstName": {
          "$ref": "#foo"
        },
        "lastName": {
          "$ref": "#bar"
        }
      },
      "definitions": {
        "bar": {
          "$id": "#bar",
          "type": "number"
        }
      }
    }
  },
  "required": [
    "nested"
  ],
  "definitions": {
    "foo": {
      "$id": "#foo",
      "type": "string"
    }
  }
}

this example will pass both validators. But for me it looks like #foo should not be reachable because of adding $id (new base URI)

[Eomm]

This validator does not allow such usage, but this allows

It is a matter of their implementation, I don't know what those are using under the hood so it is hard to understand..
I may guess:

• the schema with the nested property is a Draft 7 one, so the first validator could misunderstand the spec you are using

I have tried to update the spec here

It won't works as well

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "http://example.com/hi.json",
  "properties": {
    "nested": {
      "type": "object",
      "$id": "http://nasted.com/hi.json",
      "properties": {
        "firstName": {
          "$ref": "http://example.com/hi.json#foo"
        },
        "lastName": {
          "$ref": "#bar"
        }
      },
      "$def": {
        "bar": {
          "$anchor": "#bar",
          "type": "number"
        }
      }
    }
  },
  "$def": {
    "hello": {
      "$anchor": "#foo",
      "type": "boolean"
    }
  }
}

The spec does not state where it is allowed to put definitions

The definitions can be places into every JSON schema object, but you may fight against URI generation, spec updates and bugs.
I would avoid the burden here and use external schemas instead.

Another one thing is that theoretically I can define a new subschema everywhere by just adding an $id to it:

It depends on the spec and on the $id value

• Draft 7

A subschema's "$id" is resolved against the base URI of its parent schema.

There is an example of it
But you should follow the spec strictly and use URI, Relative URI and fragments when needed otherwise the behaviour is unpredictable based on the implementation of the schema compiler

• Draft 8/2019-09:

Things are more clearer:

The presence of "$id" in a subschema indicates that the subschema constitutes a distinct schema resource within a single schema document.

But there is the new $anchor keyword where set the fragments

• Draft 9/2020-12: most unsupported. I did not read it in depth