Diff tool gets confused when a new inline enum value is added and a new enum type is added at the sime time about oasdiff HOT 4 CLOSED

Thanks @blva.
I replicated this behavior.

from oasdiff.

Apparently, this is the expected behavior based on the current diff algorithm.

Explanation:
The sub-schemas under eventTypeName/oneOf were changed:

• Base (response-enum-one-of-inline.yaml): there are 2 enums
• Revision (response-enum-one-of-inline-2.yaml): there are 3 enums

Note that these sub-schemas are defined “inline”, meaning that they are not references to schemas under “Components”.
When oasdiff compares “inline” schemas it cannot determine which pairs of schemas correspond to each-other between base and revision.

For example, when comparing this list of schemas:

• Schema1
• Schema2

to this list of schemas:

• Schema3
• Schema4
• Schema5

oasdiff doesn't know if Schema3 corresponds to Schema1 or to Schema2, or perhaps it is a new schema that corresponds to neither of the old ones.

oasdiff actually tries to minimize the error by matching identical schemas, so in your case:

• “Billing Event Types” is unchanged
• “Cps Backup Event Types” is modified
• “New Events” is added

So oasdiff knows that “Billing Event Types” is unchanged, but it can’t determine whether the new “Cps Backup Event Types” is a modified version of the old one or whether it’s a new schema. The same logic applies to “New Events”.

In your case, there is a hint, a title, which we could use to enhance the matching but we can’t rely on it because it is optional and, moreover, it could also be modified.

So here’s a question to you, and the community:
Do you think that we should enhance the matching algorithm to compare schemas with the same title to each-other?

from oasdiff.

Hey @reuvenharrison, sorry to get back at this in delay, but I do believe we should enhance and match the same titles. But I understand that this would be then a feature request based on your explanation of the current algorithm limitation. Thanks for doing this fix I'll test this out! Also the core issue is that the actual behaviour detects a breaking change false positive when it should be just info level messages.

from oasdiff.

The fix is already available in the latest release. Please give it a try and let me know how it works.

from oasdiff.