OpenAPITools / OpenAPITools/openapi-diff

Property `type` change on referenced component schema is silently ignored

Open
#910 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug OpenAP 3.1.0 Support
Dominant language
Java
Stars
1.1k
Forks
190
PR merge metrics
No merged PRs in 30d

Description

Library version: org.openapitools.openapidiff:openapi-diff-core:2.1.7
Java: 21
OpenAPI version of test specs: 3.1.0 (also reproduces on 3.0.x)

Summary

When the only difference between two specs is a type change on a property of a referenced component schema, OpenApiCompare.fromContents reports zero changes. Both getChangedOperations() and getChangedSchemas() are empty. Other property-level changes (required list deltas, enum value deltas) on the same referenced schema are detected normally — only type swaps are dropped.

Minimal reproduction

old.yaml:

openapi: 3.1.0
info:
  title: t
  version: '1'
paths:
  /widgets:
    get:
      responses:
        '200':
          description: ok
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Widget'
components:
  schemas:
    Widget:
      type: object
      properties:
        weight:
          type: integer

new.yaml — identical except for weight.type:

openapi: 3.1.0
info:
  title: t
  version: '1'
paths:
  /widgets:
    get:
      responses:
        '200':
          description: ok
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Widget'
components:
  schemas:
    Widget:
      type: object
      properties:
        weight:
          type: string
import org.openapitools.openapidiff.core.OpenApiCompare;
import org.openapitools.openapidiff.core.model.ChangedOpenApi;
import java.nio.file.*;

public class Repro {
    public static void main(String[] a) throws Exception {
        String prev = Files.readString(Path.of("old.yaml"));
        String curr = Files.readString(Path.of("new.yaml"));
        ChangedOpenApi d = OpenApiCompare.fromContents(prev, curr);
        System.out.println("missingEndpoints: " + d.getMissingEndpoints().size());
        System.out.println("newEndpoints:     " + d.getNewEndpoints().size());
        System.out.println("changedOperations:" + d.getChangedOperations().size());
        System.out.println("changedSchemas:   " + d.getChangedSchemas().size());
    }
}
Actual output
missingEndpoints: 0
newEndpoints:     0
changedOperations:0
changedSchemas:   0
Expected output

A non-empty changedOperations (or changedSchemas) containing an INCOMPATIBLE entry for the property weight on Widget.

Other findings
  • Reproduces with OpenAPIParser + ParseOptions.setResolveFully(true) and OpenApiCompare.fromSpecifications(...).
  • Inverting the spec versions (3.1.0 ↔ 3.0.3) does not change the result.
  • The same fixture with a required: list change instead (e.g. adding weight to required) is detected correctly — changedOperations and changedSchemas are populated. So the parser does diff the referenced schema; only the type field is being skipped.
  • As a workaround, walking the resolved Schema tree manually after setResolveFully(true) and comparing Schema.getType() / Schema.getTypes() recovers the change.

Happy to put up a PR if pointers to where the schema-type comparator lives would help.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at OpenApiCompare.fromContents and fromSpecifications, using the supplied old.yaml/new.yaml reproduction with ParseOptions.setResolveFully(true). Trace how ChangedOpenApi records referenced schema changes and where Schema.getType()/getTypes() are compared. Done means the weight integer-to-string change produces a non-empty changedOperations or changedSchemas result with an INCOMPATIBLE entry, while required and enum changes remain detected.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
api, backend-api-design
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.