[BUG] Version 4 no longer supports additionalProperties with boolean value

[bopm]

Description

Generator no longer supports additonalProperties with boolean value. Error -attribute components.schemas.<...>.additionalProperties is not of type 'object' being returned for such.

openapi-generator version

It's regression for 4.0.0

OpenAPI declaration file content or url

{
  "type": "object",
  "additionalProperties": true
}

[macjohnny]

see also OAI/OpenAPI-Specification#668

[lemoinem]

The link provided by @macjohnny is somewhat misleading. At first glance, it seems to imply that boolean additionalProperties are forbidden by the Spec.

Linked from there is OAI/OpenAPI-Specification#894 which clearly states that boolean additionalProperties are allowed.

And the current (3.0.2) text of the spec is very clear about it: https://swagger.io/specification/#properties

additionalProperties - Value can be boolean or object. Inline or referenced schema MUST be of a Schema Object and not a standard JSON Schema. Consistent with JSON Schema, additionalProperties defaults to true.

This has always been the case in all of the published OAS 3.0 specs:
https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md
https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md

The Swagger 2.0 spec is not as explicit (https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md, only relevant links have been preserved):

The Schema Object allows the definition of input and output data types. These types can be objects, but also primitives and arrays. This object is based on the JSON Schema Specification Draft 4 and uses a predefined subset of it. On top of this subset, there are extensions provided by this specification to allow for more complete documentation.

Further information about the properties can be found in JSON Schema Core and JSON Schema Validation. Unless stated otherwise, the property definitions follow the JSON Schema specification as referenced here.
[...]
The following properties are taken from the JSON Schema definition but their definitions were adjusted to the Swagger Specification. Their definition is the same as the one from JSON Schema, only where the original definition references the JSON Schema definition, the Schema Object definition is used instead.
[...]

• additionalProperties

but it's a reference to JSON Schema Specification Draft 4. In particular, https://tools.ietf.org/html/draft-fge-json-schema-validation-00 states:

The value of "additionalProperties" MUST be a boolean or an object. If it is an object, it MUST also be a valid JSON Schema.

Since having additionalProperties set to false is somewhat standard in several JSON generation tools (in our case, Swashbuckle), this is a major drawback for us...

[sabba]

This bug has also broken our development pipeline, where we use the latest openapi-generator-cli docker image to validate and generate a python-flask server.
Currently we have to skip the validation with --skip-validate-spec.

Bug is still present on image v4.0.0, while it's not present on v4.0.0-beta3.

Thank you.

[macjohnny]

cc @wing328

[lemoinem]

As mentioned by sabba, disabling the validation can be used as a workaround in the meantime.

[bopm]

@wing328 by any chance is there a way to escalate it? It's really nasty to disable validation because of that.

[wing328]

@bopm yes, it's a regression in the Swagger Parser. Please open an issue in that repo instead.

[bopm]

@wing328 According to this and this it may no longer be a problem. Testing on my example right now.

[bopm]

Well, it should be fixing that, but for some reason it's not. I am pulling 4.0.1 from Docker and it keeps telling me additionalProperties is not of type 'object'.

[bopm]

Can that be connected to missing release 2.0.13 here?

[wing328]

I don't think so ...

cc @jmini who works on the parser we maintain

[bopm]

Seems like stalled issue. And yet it forces me to not use validation in production code. Can something be done about it?

cc @wing328 @jmini

[ricellis]

This appears fixed for me with the parser v2.0.13-OpenAPITools.org-2 which is included in recent 4.0.3 snapshots (I tried openapi-generator-cli-4.0.3-20190708.092710-73). So hopefully this will be resolved in the 4.0.3 release.

[wing328]

@ricellis thanks for confirming the issue has been addressed. Issue closed.

[jmini]

@ricellis I really appreciate your feedback on this. It helps to close issue.