v3.0 (bug?) - swagger compliance assertion fails in v3.0 but is ok in v2.8

Further replying to this topic as the solution was a bit too quick. If anyone from the community is interested -- there is a bug in the swagger compliance assertion currently.

Full details:

Edit: An error in the Swagger compliance assertion like this "instance type (null) does not match any allowed primitive type", even when parameter nullable is set is  to true, probably due to a limitation of swagger in the 2.0 version, which doesn't work well with nullale. The compliance assertion for a swagger 3.0 with nullable true will not fail. 

Point 2  from above reply from smartbear:

2. "instance type (string) does not match any allowed primitive type (allowed: ["object"]) checked node: [/priority] corresponding schema: [/properties/priority]"
There is an incorrect reference in the enum types. You can't use the allOf statement if you want to refer to the enum type only, because enum is a simple value, and the allOf statement is used for objects. In this case, you need to fix the definition.

Above point 2 from smartbear support was contested by our Swagger creator David:

I do not agree with point 2. allOf includes an array of schema objects. ‘{“type”: “string” } is a valid schema object.

Swagger specification screenshot:

JSON Schema draft 4 spec screenshot:

Smartbear came back with:

[...] according to the Swagger Specification, the inline or referenced schema must be a schema object, not a standard JSON schema: https://1drv.ms/u/s!AnCx6DcSb33_nRQ4LJCgqd1OAXiK.
Please see this article for reference: https://swagger.io/docs/specification/data-models/oneof-anyof-allof-not/#allof

So, it is not correct to apply the allOf keyword to this definition. [...]

David's reply:

When looking at the OpenAPI 3.0.2 documentation I read the following for allOf:

Link: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.2.md#schemaObject

• allOf - Inline or referenced schema MUST be of a Schema Object and not a standard JSON Schema.

When I look at the definition of a Schema Object (not a standard JSON Schema) I see the following:

The Schema Object allows the definition of input and output data types. These types can be objects, but also primitives and arrays.

Properties

The following properties are taken directly from the JSON Schema definition and follow the same specifications:

• required
• enum

When looking for the definition of the type property we see the following:

type - Value MUST be a string. Multiple types via an array are not supported.

This means that unlike in the JSON Schema definition only one type is supported. ‘string‘ is a valid value for the type property according to https://tools.ietf.org/html/draft-wright-json-schema-00#section-4.2

And the example section includes the following example of a Schema Object:

JSON

{

  "type": "string",

  "format": "email"

}

YAML format:

type: stringformat: email

Adding the enum property to the the example above while removing the format yields our definition:

Our definition is a schema object describing a primitive string value.

type: string
enum:
    - NORMAL
    - URGENT

This looks to be perfectly according to spec. Am I missing something that indicates that the schema objects used in the allOf array must describe objects and not primitives or arrays?

Too which finally Smartbear replied:

Yes, you're right - the schema is valid. And, there is a bug in ReadyAPI for the Swagger Compliance Assertion. I've linked your case to this bug to let you know once it's fixed.