Open seveneves opened 2 weeks ago
The problem seems to be caused by method isProductSchema
which does the following check
s.`type`.getOrElse(Nil).filter(_ != SchemaType.Null) == List(SchemaType.Object) &&
s.properties.nonEmpty &&
s == Schema(
`type` = s.`type`,
properties = s.properties,
required = s.required,
dependentRequired = s.dependentRequired,
)
And in my case last check is not fulfilled. It is caused by having $schema
set to http://json-schema.org/draft-04/schema#
. So after removing it, the comparator works fine.
I think s == Schema
should be replaced with a better check that avoids problems like the one I just described.
Would a fix be to ignore the value of $schema
on nested schemas? The spec says that embedded schemas MAY specify it, and I suppose schemas with and without $schema
are equivalent, as this only influences potential validation of the schema itself, not of the schema's semantics?
Maybe @ghik will have something to say as well :)
It might be the case that stripping $schema
should be added to this method - I don't recall exactly why it wasn't so far.
I would like to use
sttp.apispec.validation.SchemaComparator
to check if two versions of schema are compatible. But it fails to identify addition of a new optional field.The following application highlights the problem
it produces
I read that
SchemaComparator
should support such casesBut also it has the following
Which seems to be producing my output.
So it is not clear if this is a complex case or it is a bug in
SchemaComparator