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

Unexpected behaviour applying minimum clause to missing property #670

Closed
alsyia opened this issue Mar 23, 2020 · 4 comments
Closed

Unexpected behaviour applying minimum clause to missing property #670

alsyia opened this issue Mar 23, 2020 · 4 comments

Comments

@alsyia
Copy link

alsyia commented Mar 23, 2020

Hi!

I'm seeing a somewhat weird behaviour when I try to apply a conditional minimum clause to a message where the minimum clause subject is missing.

For example:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
      "amount": {
          "type": "number"
      },
      "sometimesOptional": {
        "type": "string"
      }
  },
  "if": {
      "properties": {
          "amount": {
              "minimum": 1
          }
      }
  },
  "then": {
      "required": ["sometimesOptional"]
  }
}

Applying this schema to an empty JSON doc ({}) raises the following error:

jsonschema.exceptions.ValidationError: 'sometimesOptional' is a required property

Failed validating 'required' in schema['if']['then']:
    {'required': ['sometimesOptional']}

On instance:
    {}

Is this expected? It looks like in the absence of amount the if/minimum clause is considered valid. I checked the spec but could not find anything related to this particular edge case. I'm not sure what the correct behaviour is as I'm not very familiar with JSON schemas. In classic python or javascript testing if None or undefined was greater than 1 would raise an error... Anyway, I thought I might open an issue to know if it's a bug or just a quirk of schemas :)

As a side note, I think it worked in jsonschema 2.6.0 because I've had issues only since I upgraded to 3.2.0.

For now, as a fix, I added "required": ["amount"] in my if clause so that it's only enforced if the attribute is present.

Looking into the code of 3.2.0 it looks logical at least: the minimum validator returns None because the attribute is not found and I think the if validator checks if there was an error validating the schema so...

Thank you for your time and this amazing lib! :)

@Julian
Copy link
Member

Julian commented Mar 23, 2020

Hi!

Thank you for your time and this amazing lib! :)

Thanks! Glad you like it.

Is this expected? It looks like in the absence of amount the if/minimum clause is considered valid. I checked the spec but could not find anything related to this particular edge case.

Yes, both in the current spec and all previous ones. properties applies a schema only when a property is present. If it's not present, that doesn't make the schema invalid. Making the property need to be present is exactly what required is for, just as you're using it for sometimesOptional -- maybe you meant to make amount required always?

@alsyia
Copy link
Author

alsyia commented Mar 24, 2020

Thanks for your answer!

I see! I really want sometimesOptional to be required only if amount is greather than 1 (which in my mind implied amount was there in the first place so I guess adding required in my if close was the way to go. Except if there is a better way to say "if this field is defined" in a if clause?

As a side note, do you know why it worked differently before? The example above was valid in 2.6.0. (I understand it's more like a bug fix though).

@Julian
Copy link
Member

Julian commented Mar 24, 2020

As a side note, do you know why it worked differently before? The example above was valid in 2.6.0. (I understand it's more like a bug fix though).

As I mentioned, this didn't work differently before -- would have to see specifically what you're referring to to know what you were running -- but also, 2.6.0 was before draft 7 was out, 3.x was the first version to support draft 7 of the spec -- so if you're saying you were running a draft 7 spec on pre-draft 7 validators that may be a reason why it appeared to validate successfully.

Glad you've got it working now though.

@Julian Julian closed this as completed Mar 24, 2020
@alsyia
Copy link
Author

alsyia commented Mar 24, 2020

Maybe it is, I'm not sure, that's old code. I tested the exact same example with 2.6 not realizing draft 7 was not supported at that time. Anyway, the issue was definitely on my side :/

Sorry for that, and thanks for your help!

Julian added a commit that referenced this issue Oct 30, 2023
95fe6ca Merge pull request #694 from json-schema-org/heterogeneous-additionalItems
9c88a0b Merge pull request #697 from json-schema-org/gregsdennis/add-ref-into-known-nonapplicator
fea2cf1 add tests for 2019 and 2020
6695ca3 add optional tests for `$ref`ing into known non-applicator keywords
cda4281 Merge pull request #695 from json-schema-org/ether/clean-up-subSchemas
7b9f45c move subSchemas-defs.json to subSchemas.json
e41ec0e remove unused definition files
349c5a8 Merge pull request #692 from json-schema-org/ether/fix-subSchemas-refs
451baca Merge pull request #670 from marksparkza/invalid-output-test
b8da838 Add tests for heterogeneous arrays with additionalItems
6d7a44b fix subschema locations and their $refs
ea0b63c Remove invalid output tests

git-subtree-dir: json
git-subtree-split: 95fe6ca20a90a019f4538f3670b6dd49d91dfdee
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants