Breaking changes happen when the Request payload between one version of the API and another version of the API are incompatible - meaning that the minimum viable payload from the old API version does not work with the new API version.
In the event of a new Optional field being added to the Request (or Response) payload the minimum viable request payload remains valid, therefore provided the field is correctly flagged as Required/Optional, we can lean on that to determine whether a breaking change is actually a breaking change.
Since this is going a conditional check, this commit changes this from an Error to a Warning - as whilst there are situations where this can be a breaking change; this requires understanding the change.
Breaking changes happen when the Request payload between one version of the API and another version of the API are incompatible - meaning that the minimum viable payload from the old API version does not work with the new API version.
In the event of a new Optional field being added to the Request (or Response) payload the minimum viable request payload remains valid, therefore provided the field is correctly flagged as Required/Optional, we can lean on that to determine whether a breaking change is actually a breaking change.
This fixes an issue seen in https://github.com/Azure/azure-rest-api-specs/pull/26680 and https://github.com/Azure/azure-rest-api-specs/pull/22407 and https://github.com/Azure/azure-rest-api-specs/pull/25080 where the API Definition doesn't correctly document all of the possible fields within the Request/Response payloads.
Since this is going a conditional check, this commit changes this from an Error to a Warning - as whilst there are situations where this can be a breaking change; this requires understanding the change.