Validator cache doesn't account for list: (true | false) changes

[leppert]

If you reference the same schema, first with list: true and then with list: false, the second call will return a cached version of the schema with the array wrapper from list: true. Perhaps the list param should be taken into account when generating the cache key?

[ysbaddaden]

I just stumbled upon this bug that created random errors in my test suite. I worked around it by clearing the cache after each validation where list is true.

[tegon]

I also had this bug, my workaround was to clear the cache for each spec.

JSON::Validator.clear_cache
JSON::Validator.validate!(schema_path, response_body, default_optitons.merge(options))

Of course this hurts performance, and i agree with @leppert that the cache key could be different for list

[lleger]

This also bit me. Clearing the cache worked. Caching should definitely take into account list: true.

[skoushan]

Same here

[infiton]

Same here, this created random pass/fail effects in my test suite

[iainbeeston]

As mentioned, the issue is that when we create an array schema, we modify the original (by wrapping it in a new schema that takes an array of the original - see JSON::Schema.to_array_schema) but then when we store it in the cache we use the uri of the original schema (see JSON::Validator.add_schema). If we modify the schema at all we should also give it a new uri, to ensure that it doesn't cause a cache collision with the original.

[RST-J]

This new URI has to be deterministic, we cannot just generate a UUID (which was my first thought) or revalidation will fail again for basically the same reason.