Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unevaluatedProperties not evaluating properties stemming from $ref schemas loaded through nested allOf #1123

Closed
Whathecode opened this issue Oct 26, 2024 · 0 comments · Fixed by #1124
Labels

Comments

@Whathecode
Copy link
Contributor

I believe I found a bug when determining unevaluatedProperties (version 1.5.2). For now, I'll show where I run into issues in context of my actual codebase. My hope is this can already convey expectations vs. actual result. I can try creating a small repro later.

Take the follow schema:

{
  "$schema": "https://json-schema.org/draft/2019-09/schema",
  "type": "object",
  "allOf": [ { "$ref": "PrimaryDeviceConfiguration.json#PrimaryDeviceConfiguration" } ],
  "properties": {
    "__type": { "const": "dk.cachet.carp.common.application.devices.Smartphone" }
  },
  "unevaluatedProperties": false,
  "$defs": {
    "DeviceRegistration": {
      "$anchor": "DeviceRegistration",
      "$ref": "DefaultDeviceRegistration.json"
    }
  }
}

PrimaryDeviceConfiguration.json#PrimaryDeviceConfiguration in turn has a nested allOf:

    "PrimaryDeviceConfiguration": {
      "$anchor": "PrimaryDeviceConfiguration",
      "allOf": [ { "$ref": "DeviceConfiguration.json#DeviceConfiguration" } ],
      "properties": {
        "isPrimaryDevice": { "const": true }
      },
      "required": [ "isPrimaryDevice" ]
    }
  }

DeviceConfiguration.json#DeviceConfiguration in turn defines a roleName property.

The base schema referenced (PrimaryDeviceConfiguration.json#PrimaryDeviceConfiguration) doesn't set unevaluatedProperties anywhere. The intent is for the base types to allow extension, but this specific type, defined in this schema, shouldn't have any additional unknown properties.

However, with this setup, I get warnings on properties which are defined through my allOf schema.

'roleName' is not evaluated and the schema does not allow unevaluated properties

When I add this property directly to allOf in the first schema, the error is gone.

  "allOf": [
    { "$ref": "PrimaryDeviceConfiguration.json#PrimaryDeviceConfiguration" },
    {
      "properties": {
        "roleName": { "type": "string" }
      }
    }
  ]

When I reference a definition within the same schema, the error is also gone.

  "allOf": [
    { "$ref": "PrimaryDeviceConfiguration.json#PrimaryDeviceConfiguration" },
    { "$ref": "#/$defs/Test" }
  ]
  ...
  "$defs": {
    "Test": {
      "$anchor": "Test",
      "properties": {
        "roleName": { "type": "string" }
      }
    }
  }

When I add this property directly to the second schema (PrimaryDeviceConfiguration.json#PrimaryDeviceConfiguration), the error is also gone.

    "PrimaryDeviceConfiguration": {
      "$anchor": "PrimaryDeviceConfiguration",
      "allOf": [ { "$ref": "DeviceConfiguration.json#DeviceConfiguration" } ],
      "properties": {
        "isPrimaryDevice": { "const": true },
        "roleName": { "type": "string" }
      },
      "required": [ "isPrimaryDevice" ]
    }
  }

But, seemingly the property (roleName) being defined in the lowest schema (DeviceConfiguration.json#DeviceConfiguration) doesn't get picked up.

I would expect the JSON schema specification to dictate these also need to be included, but seemingly this library only recurses one level deep.

@Whathecode Whathecode added the bug label Oct 26, 2024
Whathecode added a commit to cph-cachet/carp.core-kotlin that referenced this issue Oct 26, 2024
This seems to have introduced better evaluation of `allOf` and `oneOf` references.

However, it does seem to introduce a bug which causes it not to consider properties in nested schemas more than 1 level deep when evaluating `unevaluatedProperties`: networknt/json-schema-validator#1123

Therefore, this requirement has been removed in schemas where it was causing current validation to fail. Note that not all concrete types are currently evaluated (#404), so there are many other schemas which would also fail if they were to be evaluated.
Whathecode added a commit to cph-cachet/carp.core-kotlin that referenced this issue Oct 27, 2024
This seems to have introduced better evaluation of `allOf` and `oneOf` references.

However, it does seem to introduce a bug which causes it not to consider properties in nested schemas more than 1 level deep when evaluating `unevaluatedProperties`: networknt/json-schema-validator#1123

Therefore, a hack was introduced to make sure validation succeeds.. Note that not all concrete types are currently evaluated (#404), so there are many other schemas which would also fail if they were to be evaluated, and they would need to apply a similar fix.
Whathecode added a commit to cph-cachet/carp.core-kotlin that referenced this issue Oct 27, 2024
This seems to have introduced better evaluation of `allOf` and `oneOf` references.

However, it does seem to introduce a bug which causes it not to consider properties in nested schemas more than 1 level deep when evaluating `unevaluatedProperties`: networknt/json-schema-validator#1123

Therefore, a hack was introduced to make sure validation succeeds.. Note that not all concrete types are currently evaluated (#404), so there are many other schemas which would also fail if they were to be evaluated, and they would need to apply a similar fix.
Whathecode added a commit to cph-cachet/carp.core-kotlin that referenced this issue Oct 28, 2024
This seems to have introduced better evaluation of `allOf` and `oneOf` references.

However, it does seem to introduce a bug which causes it not to consider properties in nested schemas more than 1 level deep when evaluating `unevaluatedProperties`: networknt/json-schema-validator#1123

Therefore, a hack was introduced to make sure validation succeeds.. Note that not all concrete types are currently evaluated (#404), so there are many other schemas which would also fail if they were to be evaluated, and they would need to apply a similar fix.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant