Fixing an issue where new Optional properties were incorrectly flagged as a breaking change #283
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 Azure/azure-rest-api-specs#26680 and Azure/azure-rest-api-specs#22407 and Azure/azure-rest-api-specs#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.