[openapi-response-validator] valid body fails incorrectly against allOf schemas with additionalProperties: false
See original GitHub issueHi,
Thanks for this great package!
@rolfisub and I found a bug where if you validate a response body against allOf
multiple schemas where one of them has additionalProperties: false
, then you get a failure (when you should get no failures).
I.e., this test should pass:
module.exports = {
constructorArgs: {
responses: {
'2XX': {
schema: {
allOf: [
{
type: 'object',
properties: {
expectedProperty1: {
type: 'string'
}
}
},
{
type: 'object',
properties: {
expectedProperty2: {
type: 'string'
}
},
additionalProperties: false,
},
]
}
}
},
definitions: null
},
inputStatusCode: 200,
inputResponseBody: {
expectedProperty1: 'foo',
expectedProperty2: 'bar',
},
expectedValidationError: void 0
};
But instead it fails with this error:
{
message: 'The response was not valid.',
errors: [
{
path: 'response',
errorCode: 'additionalProperties.openapi.responseValidation',
message: 'should NOT have additional properties'
}
]
}
This bug seems to occur only in this specific case. For example, schemas with additionalProperties: true
seem to work correctly, as do schemas with allOf
just one schema, with additionalProperties: false
, e.g.:
allOf: [
{
type: 'object',
properties: {
expectedProperty1: {
type: 'string'
}
}
additionalProperties: false,
},
// just one schema, with `additionalProperties: false`
]
// this passes and fails when it should
Looking at the code of openapi-response-validator, it seems that you outsource your validation to Ajv, which I guess is this one https://github.com/epoberezkin/ajv/issues?utf8=✓&q=additionalProperties. I see recent mention of unexpected errors for anyOf schemas with additionalProperties: false, but they were resolved 2 months ago, and I’m a bit out of my depth spotting the fix.
Before I raise an issue there, I wondered if you have any ideas/thoughts on this?
Issue Analytics
- State:
- Created 4 years ago
- Comments:7 (3 by maintainers)
Top GitHub Comments
Hi @Envek , we ran into the same issue. We solved this by having a
source
version of our specification from which we generated the actual fully resolved version. You can see it here: https://github.com/AliceO2Group/Bookkeeping/tree/master/spec , it includes the required source code (in JavaScript). Do note that theconvert.js
file does more than just resolving, it will also sort members.Finally I solved it by using json-schema-merge-allof library to preprocess existing schema.
It works like a charm with code like this:
See https://github.com/mokkabonna/json-schema-merge-allof/issues/26 for more details about why it is so verbose 😄