-
Notifications
You must be signed in to change notification settings - Fork 39
ExpandAllOf() throws "incompatible properties" if schemas are compatible but not equal #347
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
It might be dangerous to compare on content rather than name, because schemas that are the same today might not be the same tomorrow. In fact, it's possible that two different schemas exist simply to allow them to evolve independently. |
Can you elaborate on this, or provide an example to illustrate what you mean? Why do you think it might be dangerous to allow my example spec above? If either schema changes, the BreakingChanges tool will run again on the PR. Note this error happens when we are pre-processing the spec, before we even get to comparing two specs. The chain of events:
I also think this is a more general case of the problem we fixed in #329, where we decided to allow openapi-diff/src/test/specs/compatible-properties.json Lines 10 to 51 in 8850294
|
Okay ... now I understand. Anything that is a |
Sounds good, let me try to create a PR to see how hard this will be to fix. |
The following spec should be valid per JSON Schema and Swagger. However, we throw error
incompatible properties
when trying to process it, sinceDogOwner.pet
is typeDog
, which is compatible with but not equal toPetOwner.pet
of typePet
.openapi-diff/src/lib/util/resolveSwagger.ts
Line 250 in 8850294
@JeffreyRichter, @mikekistler: Do you think the code should be changed to allow types that are compatible but not equal? If so, should it be conditioned on whether the swagger is handwritten or typespec-generated, under the assumption that SDKs for TypeSpec will be generated directly from TypeSpec and not the intermediate Swagger?
We recently fixed a similar issue in #329, although in this case the types were identical with just an extra step of indirection.
@markcowl and I believe this is valid swagger, but some of our SDK generators may not handle it correctly, which might be why it's not allowed in
openapi-diff
. However,openapi-diff
should not be responsible for this. It should be tested directly by the SDK generation tests.Repro Steps
Save spec below to file
test.json
, then runnpx @azure/oad test.json test.json
.The text was updated successfully, but these errors were encountered: