Two path items have the same signature

[Jeb135]

Hello, I have an API that I am trying to use openapi-diff to detect breaking changes with, however running into the following error when running the diff with the latest docker image.

I have many many paths in my API That look something like this:

• /Resource/{id}
• /Resource/{name}

My API is built in .NET Framework, and openapi json files generated using Swashbuckle.

These endpoints are unique in my project, as the different values in the paths de-serialize to either an integer for the {id} path, or a string for the {name} path.

Based on the error message, it seems to be converting both of these paths into the path template "/Resource/{}" which is technically correct, but then fails because there are multiple with the same path.

Anyone have any ideas of what I can do to resolve this? Additionally, I cant get the cli to compile or find any instructions on how to compile the cli, if anyone has those that would be helpful so I can modify the code to try and find a fix.

Full error:

Unexpected exception. Reason: Two path items have the same signature: /Resource/{}
java.lang.IllegalArgumentException: Two path items have the same signature: /Resource/{}
	at org.openapitools.openapidiff.core.compare.PathsDiff.lambda$null$1(PathsDiff.java:54)
	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:51)
	at java.util.LinkedHashMap$LinkedKeySet.forEach(LinkedHashMap.java:559)
	at org.openapitools.openapidiff.core.compare.PathsDiff.diff(PathsDiff.java:44)
	at org.openapitools.openapidiff.core.compare.OpenApiDiff.compare(OpenApiDiff.java:96)
	at org.openapitools.openapidiff.core.compare.OpenApiDiff.compare(OpenApiDiff.java:64)
	at org.openapitools.openapidiff.core.OpenApiCompare.fromSpecifications(OpenApiCompare.java:102)
	at org.openapitools.openapidiff.core.OpenApiCompare.fromLocations(OpenApiCompare.java:91)
	at org.openapitools.openapidiff.cli.Main.main(Main.java:174)

[joschi]

These endpoints are unique in my project, as the different values in the paths de-serialize to either an integer for the {id} path, or a string for the {name} path.

@Jeb135 The problem here is that the OpenAPI specification doesn't express this and OpenAPI Diff cannot know this.

I would also argue that this is bad practice (from a client point of view) because as a user of that API, you don't really know why it would behave differently when sending either a string or a numeric a value (disguised as a string) in the URL path.

[joschi]

@Jeb135 Could you share the generated OpenAPI specification(s) which cause the issue you've described?