-
Notifications
You must be signed in to change notification settings - Fork 164
False positive breaking change reported when removing an optional field from a response #198
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Would you be interested if I contribute a PR to fix this issue? |
There is another way to look at -- if "optional" meant that sometimes the field is returned and sometimes it isn't (based on the attributes of the request or environment), then removing the field could break existing clients that were coded to expect it (even though the spec says that they shouldn't have). So although you can assert in your case it is not a compatibility problem in your client, it does represent a potential compatibility problem for other clients. |
It can be even more complicated. For example, Confluent Schema Registry defines several compatibility types: https://docs.confluent.io/platform/current/schema-registry/avro.html#compatibility-types Nothing to do with OpenAPI but a related concept worth looking at. |
Shouldn’t this be modeled with a |
Diff: --- core/src/test/resources/issue-198-1.json 2021-02-28 18:07:23.000000000 +0100
+++ core/src/test/resources/issue-198-2.json 2021-02-28 18:07:46.000000000 +0100
@@ -114,10 +114,6 @@
"value": {
"type": "integer",
"format": "int32"
- },
- "timestamp": {
- "type": "string",
- "format": "date-time"
}
},
"required": [ |
We are experiencing the same issue as OP and also believe it is a backwards compatible change. |
… removing an optional field from a response
…nal field from a response. Closes OpenAPITools#198
Hi, I've found this issue because the current behavior is the opposite of how I expect openapi-diff to behave. At the very least this behavior should be configurable. My suggestion is to add new configuration properties for request and response which control whether this is considered a breaking change or not. p.s. |
@myoffe, I agree with you on this topic. All decisions regarding breaking/non-breaking should be configurable from a user perspective, as this is a "holy war" question. Please look at this discussion, I've collected all concerns raised in this repo regarding this topic. So at the moment, we have BackwardIncompatibleProp.java. Please check it out, may be it can address your particular case. |
Thanks @DrSatyr I've checked the props file, I did not find something that can control this behavior. |
I’ve noticed that removing an optional field from a response is flagged as a breaking change.
Old OpenAPI document
Note the presence of the optional field
timestamp
in thecounter.Counter
component.New OpenAPI document
Note that the field
timestamp
is absent from thecounter.Counter
component.I expect such a change to be backward compatible: clients already know how to deal with the absence of the field
timestamp
since this one was optional in the first place.The text was updated successfully, but these errors were encountered: