no schema with key or ref

[Jesbjerg]

Prerequisites

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

Last working version

4.0.2

Stopped working in version

4.2.0

Node.js version

16.15.0

Operating system

macOS

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

12.4

💥 Regression Report

Anchors are not supported in attribute $id whenever the schema has an anyof. In my case a union type from Typebox.

Deps:
"@sinclair/typebox": "^0.24.20",
"fastify": "^4.3.0"

Example:
export const Response = Type.Object({
test: Type.Union([Type.Boolean(), Type.String()])
}, {
$id: "urn:test#response", // fails
// $id: "urn:test", // ok
description: "Schema for test",
additionalProperties: false
})

Error:
Error on response: "statusCode": 500,
"error": "Internal Server Error",
"message": "no schema with key or ref "urn:test:test:test:test:test#response#/properties/test/anyOf/0""

Steps to Reproduce

The referred issue contains both a project and minimal code snippet reproducing the error.
sinclairzx81/typebox#209

Expected Behavior

Expect fast-json-stringify to parse the JSON correctly, as the # is allowed for ajv in $id

[mcollina]

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

[ivan-tymoshenko]

@Jesbjerg Thanks for your report. The part of the reference that starts from the # is used to define the JSON pointer (path inside the JSON schema). You shouldn't use # in your $id properties. I think this is a similar discussion fastify/fastify#3965.

You see this issue in the oneOf/anyOf case because this is one of the cases when we get the schema by schema $id.

If you see the reason why this should be supported or have a link to the specification where it is supported, please share. I can not know something, but even if we would like to support the # symbol in the $id, it seems unclear to me how we would split schema id from JSON pointer then.

[Jesbjerg]

@ivan-tymoshenko I don't know if we have a good reason for having written our schemas like this, or if changing it has major implications. If it is non-standard to put # into $id's - maybe we should go look for an alternative approach. I want to check with my colleague tomorrow. Thanks for the quick response.