Hello everyone!
When using @ibm/openapi-validator (which leverages Spectral) with the ibm:oas3 ruleset, the oas3-valid-schema-example or ibm-valid-schema-example rules does not report errors for additionalProperties: false or casing mismatches (e.g., ID instead of id) in example values. This occurs even when the example is inlined directly into the OpenAPI specification, and the schema explicitly sets additionalProperties: false.
The validator should identify properties present in the response example that are not defined in the schema (or have incorrect casing, which is treated as an additional property when additionalProperties: false is set) and flag them as errors. Currently, Total number of errors remains 0 for these specific schema validation issues, while other rules fire correctly.
# test.yaml
openapi: 3.0.0
info:
title: Example Validation Test
version: 1.0.0
paths:
/test:
get:
responses:
'200':
description: Test Response
content:
application/json:
schema:
type: array
items:
$ref: '#/components/schemas/Result'
examples:
ExampleOne:
$ref: '#/components/examples/ExampleOne'
components:
schemas:
Result:
type: object
properties:
id:
type: string
code:
type: string
required:
- id
- code
additionalProperties: false # Explicitly disallows additional properties
ExampleOne:
value:
Test: "Test" # Should be extra
ID: "hello" # should be trigger error
CoDe: ">" # should be trigger error
and
// .spectral.js
const ibmCloudValidationRules = require('@ibm-cloud/openapi-ruleset');
module.exports = {
extends: [ ibmCloudValidationRules ],
rules: {
'oas3-valid-schema-example': 'error', // Set to 'error' to catch validation issues
'ibm-parameter-order': 'warn',
}
};
Hello everyone!
When using @ibm/openapi-validator (which leverages Spectral) with the ibm:oas3 ruleset, the oas3-valid-schema-example or ibm-valid-schema-example rules does not report errors for additionalProperties: false or casing mismatches (e.g., ID instead of id) in example values. This occurs even when the example is inlined directly into the OpenAPI specification, and the schema explicitly sets additionalProperties: false.
The validator should identify properties present in the response example that are not defined in the schema (or have incorrect casing, which is treated as an additional property when additionalProperties: false is set) and flag them as errors. Currently, Total number of errors remains 0 for these specific schema validation issues, while other rules fire correctly.
and