Number formats validated on a warning level only

[Former user]

For given OpenAPI 3.x schema:

Pet:
  type: object
  properties:
    age:
      type: integer
      format: int32

and JSON payload e.g.:

{ "age": 999999999999999999999999999999999 }

I would expect validator to report some reasonable problem that the number used in payload is not a 32-bit signed integer (like it's defined in OpenAPI 3.x specification), but the validator reports nothing. The reason is that Int32Attribute is reported only on warning level which is not reflected to a final validation report. This also applies to int64, float and double formats.

Is this expected behaviour? If it is, is there any possibility how to enable reporting for these number formats using OpenApiInteractionValidator as main validation component and without any additional custom validation?

[Jiri Mikulasek]

I was examining the situation and here is what I found:

1. The number formats are not mandatory in OpenAPI 3.X, that’s probably why their validation is not reported

2. But currently it’s hard to make those validations reported even only optional cause of following reasons:

   1. The current Int32Attribute (and company) is hooked as addition into underlying JsonSchemaValidator and reporting to WARNING, but messages with lower level than ERROR coming from JsonSchemaValidator are swallowed (which is IMHO correct)
   2. Changing the level of JsonSchemaValidator reports to WARNING is probably not an option - in that case many other unwanted messages could be emitted
   3. Changing Int32Attribute to emit ERROR would work, however since it’s singleton class, there is no current mechanism to allow this by configuration
   4. Changing Int32Attribute to emit ERROR and on top of that decide whether it will be emitted somewhere in SchemaValidator would probably be the most correct way, but again the suitable configuration mechanism is missing in the library

So far the analysis. In case somebody of maintainers gives me the feedback which way is the wanted/feasible one, I will be happy to contribute the code.

‌

[Peter Plocháň]

Well, even formats are not mandatory in OpenAPI 3.X, the validator documentation says that they are supported. See Supported Data Type Formats section in OpenAPI v3 Specification Support document.

[James Navin]

Thanks for doing the investigation - much appreciated!

The preferred approach for controlling the level at which messages are reported is via the “levels” mechanism - see the README in https://bitbucket.org/atlassian/swagger-request-validator/src/master/swagger-request-validator-core/ for details on how this is configured if you aren’t familiar with it. Ideally whatever solution we come up with can be controlled with this mechanism.

Without having looked at it too deeply Id say your option (4) would be the preferred way. It would probably look something like:

1. Change the attributes to emit error level messages
2. Update default-levels.properties to set them back to WARN level by default (but then allow users who want to to increase that to ERROR level via the normal mechanism)

The complication you may run into is that the levels mechanism will use a key of the form validation.<request|response>.<body|parameter>.schema.<keyword>` and in this case keyword will be format for all types. If you wanted/needed to differentiate which format was in error you might need to adjust how the key is created - perhaps simply appending the type on the end would work since those levels are hierarchical.

Hope this helps - more than happy to discuss further.

Cheers,

James

[James Navin]

Actually - the more I think on it the more I'm inclined to say leave them at ERROR level and allow people to turn them off if they don’t want them on.

[James Navin]

Available in v2.10.0