Overloaded paths are treated as equal regardless of parameter format

[DrSatyr]

Support for overloaded paths was added as addressed in this GitHub issue. However, it does not cover cases where the type of overloaded parameters is equal, regardless of format.

Example spec:

openapi: 3.0.2
info:
  title: Projects API
  version: 1.0.0
paths:
  /projects/{key}:
    get:
      parameters:
        - in: path
          name: key
          required: true
          schema:
            type: string
      responses:
        '200':
          description: 'Success'
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/SampleResponse'
  /projects/{uid}:
    get:
      parameters:
        - in: path
          name: uid
          required: true
          schema:
            type: string
            format: uuid
      responses:
        '200':
          description: 'Success'
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/SampleResponse'
components:
  schemas:
    SampleResponse:
      type: object
      properties:
        id:
          type: integer
        uid:
          type: string
        name:
          type: string
      required:
        - id
        - uid
        - name

In this case key parameter of type "string" is not equal to uid parameter of type "string" with format "uuid". This causes folowing exception:

Unexpected exception. Reason: Two path items have the same signature: /projects/{}
java.lang.IllegalArgumentException: Two path items have the same signature: /projects/{}
        at org.openapitools.openapidiff.core.compare.PathsDiff.lambda$null$1(PathsDiff.java:50)
        at java.util.function.BinaryOperator.lambda$minBy$0(BinaryOperator.java:59)
        at java.util.stream.ReduceOps$2ReducingSink.accept(ReduceOps.java:123)
        at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
        at java.util.Iterator.forEachRemaining(Iterator.java:116)
        at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
        at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
        at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
        at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
        at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
        at java.util.stream.ReferencePipeline.reduce(ReferencePipeline.java:546)
        at java.util.stream.ReferencePipeline.min(ReferencePipeline.java:587)
        at org.openapitools.openapidiff.core.compare.PathsDiff.lambda$diff$3(PathsDiff.java:48)
        at java.util.LinkedHashMap$LinkedKeySet.forEach(LinkedHashMap.java:559)
        at org.openapitools.openapidiff.core.compare.PathsDiff.diff(PathsDiff.java:41)
        at org.openapitools.openapidiff.core.compare.OpenApiDiff.compare(OpenApiDiff.java:95)
        at org.openapitools.openapidiff.core.compare.OpenApiDiff.compare(OpenApiDiff.java:66)
        at org.openapitools.openapidiff.core.OpenApiCompare.fromSpecifications(OpenApiCompare.java:101)
        at org.openapitools.openapidiff.core.OpenApiCompare.fromLocations(OpenApiCompare.java:90)
        at org.openapitools.openapidiff.cli.Main.main(Main.java:169)

[RobPurcellUK]

We've found the exact same issue - two endpoints, one taking string and one taking string($uuid).

[DrSatyr]

So the PR is ready, @wing328 any updates on #598 (comment) ? Still no candidates?