Does whitelisting work for nested validation?

[Andrew Thompson]

I have a spec which uses discriminators and all-of.

I tried to whitelist the additional properties problem using

ValidationErrorsWhitelist whitelist = ValidationErrorsWhitelist.create() .withRule( "Ignore additional properties", allOf( messageHasKey(SchemaValidator.ADDITIONAL_PROPERTIES_KEY)
)

Well, it didn't work so I spent some time in the debugger. It looks to me that the problem is that the whitelist only applies to the "top level" of the spec. The rules in the whitelist don't "inherit down" to the validation of the discriminator and the "all-of", which are recursive/nested validations, but only applies to the top level error messages returned by the outermost ValidationReport.

Or said another way, I checked in the debugger which messages are passed to each WhiteListRule.matches() and the underlying additional properties message is never actually passed to the rule. It rolls up to a "bad discriminator" check, by which time it is too late to whitelist it.

Does this make sense? Is it intended?

[Fabrice Gabolde]

I also have a spec that uses allOf, but not discriminators. I have a similar symptom to the OP though: errors are apparently whitelisted, but the allOf validation still fails. Here's what this looks like from the payload of com.atlassian.oai.validator.springmvc.InvalidResponseException (some output transformed to protect the innocent):

{
    "key" : "validation.response.body.schema.allOf",
    "level" : "ERROR",
    "message" : "[Path '/blorple/0'] Instance failed to match all required schemas (matched only 1 out of 2)",
    "additionalInfo" : [ "/properties/blorple/items/allOf/0: String \"2021-03-30T14:04:33.362\" is invalid against requested date format(s) [yyyy-MM-dd'T'HH:mm:ssZ, yyyy-MM-dd'T'HH:mm:ss.[0-9]{1,12}Z]", "/properties/blorple/items/allOf/0: String \"2021-03-30T14:04:33.362\" is invalid against requested date format(s) [yyyy-MM-dd'T'HH:mm:ssZ, yyyy-MM-dd'T'HH:mm:ss.[0-9]{1,12}Z]" ],
    "nestedMessages" : [ {
      "key" : "validation.response.body.schema.format.date-time",
      "level" : "IGNORE",
      "message" : "[Path '/blorple/0/collected_at'] String \"2021-03-30T14:04:33.362\" is invalid against requested date format(s) [yyyy-MM-dd'T'HH:mm:ssZ, yyyy-MM-dd'T'HH:mm:ss.[0-9]{1,12}Z]"
    }, {
      "key" : "validation.response.body.schema.format.date-time",
      "level" : "IGNORE",
      "message" : "[Path '/blorple/0/created_at'] String \"2021-03-30T14:04:33.362\" is invalid against requested date format(s) [yyyy-MM-dd'T'HH:mm:ssZ, yyyy-MM-dd'T'HH:mm:ss.[0-9]{1,12}Z]"
    } ],
    "context" : {
      "requestPath" : "/api/snugdorf/3",
      "responseStatus" : 200,
      "location" : "RESPONSE",
      "requestMethod" : "GET"
    }
  }

There is more of the same in the exception, but as in the excerpt the only validation errors are:

• validation.response.body.schema.format.date-time which is properly IGNOREd using my customized level resolver, at least until we fix our API’s datetime formatting
• validation.response.body.schema.allOf which is the only ERROR level message in the entire exception, so apparently causes the overall validation failure

‌