The path signature MUST be unique.

[asward]

Describe the bug

When generating source the project build fails with multiple The path signature 'xyz' MUST be unique.

I'm trying to generate an sdk/source for the JIRA Rest API (https://developer.atlassian.com/cloud/jira/platform/rest/v3/intro/#about). Their api defines a number of endpoints with non-unique path signatures.

/rest/api/2/field/{fieldId}

/rest/api/2/field/{id}

Notably, the operationId of these paths are unique, and the http method also differs.

Even excluding these operationsId(s) from the build via .csproj raises the same error.

Steps to reproduce the bug

Generate code using the jira platform api (https://developer.atlassian.com/cloud/jira/platform/rest/v3/intro/#about)

Expected behavior

I expect 'path signature' to be considered in combination with http method when evaluating endpoint uniqueness.

Screenshots

No response

NuGet package version

0.26.0

Additional context

No response

[HavenDV]

This library depends on Microsoft.OpenAPI, which is far from perfect. It would be better to create this issue there, but support is extremely slow there - https://github.com/microsoft/OpenAPI.NET

[HavenDV]

Maybe ignoring these errors could work, I need to check if this introduces any problems during parsing.
Now during parsing there are Errors and Warnings. And the library stops processing only for errors. And these problems are also errors, although it is possible that they will work correctly even like this. It is necessary to check

[asward]

Would it be possible to tailor the api spec before sending to open ai, in a way that simply removes unwanted operationIds?

[asward]

So looking into OpenAPI a bit I found this issue (microsoft/OpenAPI.NET#472), which seems to indicate this is 'per the OpenAPI spec' to disallow identical paths. I assume the correct way to have multiple methods with the same path is to nest them as such in the json/yaml.

It is a bit frustrating that the jira spec is claimed to be OpenAPI but doesn't conform. I'll try to take it up with them.

It would be nice to be able to tailor a full spec prior to generation (and errors) given that it's so easy to have a non-conformance like this that stops the rest of the SDK generation. But I'll leave that up to you if it's worth fixing - it's a bandaid to a larger issue, but does add some utility to this tool.

Feel free to close this issue.

Thanks!

[HavenDV]

Would it be possible to tailor the api spec before sending to open ai, in a way that simply removes unwanted operationIds?

At the moment filtering is only available after successful parsing (and is not documented), which is blocked by this issue. But I think you can use some other tools, for example from the npm stack, to do this

It would be nice to be able to tailor a full spec prior to generation (and errors) given that it's so easy to have a non-conformance like this that stops the rest of the SDK generation. But I'll leave that up to you if it's worth fixing - it's a bandaid to a larger issue, but does add some utility to this tool.

I totally agree with you, but now I mostly configure some scripts via console application - as far as I remember there was a similar issue for Chroma here and I just removed one of these paths:
https://github.com/tryAGI/Chroma/blob/main/src/helpers/FixOpenApiSpec/Program.cs
Then I use it in the generation script:
https://github.com/tryAGI/Chroma/blob/main/src/libs/Chroma/generate.sh