Deleted or renamed properties are marked as backwards compatible

[Patrick-Bayer]

Hello folks,

i am testing your library as a maven plugin with version: 'org.openapitools.openapidiff:openapi-diff-core:2.1.0-beta.11' and discovered that the following changes do not result in failure due to backwards incompatibility even though they should, right?

1. Removing properties from schemas
2. Renaming properties

[Sanady]

Hello @Patrick-Bayer , I am facing same issue.

[DrSatyr]

Hello folks, mostly all incompatibility rules are collected in BackwardIncompatibleProp. As you can see it has:

• RESPONSE_REQUIRED_DECREASED
• REQUEST_BODY_REQUIRED_INCREASED.

Seems, author decided to only treat new required props on request and missing required props on response as incompatible. So it depends on the point of view.
From my perspective - removing any payload property is a breaking change as API consumer can depend on it.

So the openapi-diff as a library should be smart enough to allow to configure of what is considered compatible change, and what is not. This behavior is configurable through the config file, but frankly speaking, it does not cover all possible cases. Good point to extend and review all the rules.

[DrSatyr]

BTW - REQUEST_BODY_REQUIRED_INCREASED is never used. Looks like a bug.

[nakulshukla08]

Is there an update on this issue? I am also facing the same issue where a compatibility break in terms of schema change in response doesn't mark the diff as incompatible. Below is the example -

Original Spec

openapi: "3.0.0"
info:
  title: Sample API
  version: "1.0.0"
paths:
  /users:
    get:
      summary: Get all users
      responses:
        "200":
          description: A list of users
          content:
            application/json:
              schema:
                type: array
                items:
                  type: object
                  properties:
                    id:
                      type: string
                    name:
                      type: string

Updated spec

openapi: "3.0.0"
info:
  title: Sample API
  version: "2.0.0"
paths:
  /users:
    get:
      summary: Get all users
      responses:
        "200":
          description: A list of users
          content:
            application/json:
              schema:
                type: array
                items:
                  type: object
                  properties:
                    id:
                      type: string
                    fullname:  # Breaking change (renamed `name` → `fullname`)
                      type: string

This looks like a bug to me, but let me know if there is a configuration which would evaluate this diff as incompatible.

[DrSatyr]

@nakulshukla08 there is an idea to solve this problem within the scope of discussion. But the first priority at the moment is to get 2.1.0 release happen.

Anyway, any contributions to discussion and related issues are appreciated, feel free to contribute.