Changing response field type from `oneOf: string, number` to `string` shouldn't break

Commencez par les fichiers base.yml et revision.yml fournis et exécutez openapi-diff breaking base.yml revision.yml pour reproduire le résultat de compatibilité signalé. Suivez le chemin de comparaison des schémas pour la propriété de réponse id, puis ajoutez une couverture montrant que restreindre oneOf à type: integer est accepté et qu'aucun résultat de rupture de compatibilité n'est signalé.

Describe the bug
In the response body, if you change the following field:

content:
  application/json:
    schema:
      properties:
        id:
          oneOf:
            - type: integer
            - type: string
      required:
        - id
      type: object

to:

content:
  application/json:
    schema:
      properties:
        id:
          type: integer
      required:
        - id
      type: object

Then openapi-diff reports this as a breaking change.

To Reproduce

openapi: 3.0.1
info:
  title: User Service
  version: 1.0.0
paths:
  /users:
    post:
      requestBody:
        content:
          application/json:
            schema:
              type: object
              properties:
                name:
                  type: integer
              required:
                - name
        required: true
      responses:
        201:
          description: Created
          content:
            application/json:
              schema:
                properties:
                  id:
                    oneOf:
                      - type: integer
                      - type: string
                required:
                  - id
                type: object

openapi: 3.0.1
info:
  title: User Service
  version: 1.0.0
paths:
  /users:
    post:
      requestBody:
        content:
          application/json:
            schema:
              type: object
              properties:
                name:
                  type: integer
              required:
                - name
        required: true
      responses:
        201:
          description: Created
          content:
            application/json:
              schema:
                properties:
                  id:
                    type: integer
                required:
                  - id
                type: object

1. Download the two files base.yml and revision.yml
2. Run openapi-diff breaking base.yml revision.yml
3. Observe the following output:

==========================================================================
==                            API CHANGE LOG                            ==
==========================================================================
                               User Service
--------------------------------------------------------------------------
--                            What's Changed                            --
--------------------------------------------------------------------------
- POST   /users
  Return Type:
    - Changed 201 Created
      Media types:
        - Changed application/json
          Schema: Broken compatibility
          Changed property type: id (object -> integer)
--------------------------------------------------------------------------
--                                Result                                --
--------------------------------------------------------------------------
                 API changes broke backward compatibility
--------------------------------------------------------------------------

Expected behavior
openapi-diff shouldn't mark this as a breaking change. Actually, the response body should be considered as a covariant contract: narrowing a field type isn't a breaking change.