gRPC SwaggerGen does not handle conflicting paths

[adam8797]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When designing an gRPC interface that follows the Google AIPs (Specifically in this case, API-131, a GET request should be mapped as follows:

rpc GetWidget (WidgetRequest) returns (WidgetResponse) {
  option (google.api.http) = {
    get: "/v1/{name=widgets/*}"
  };
};

Lets say we have another service which also has a GET endpoint:

rpc GetThing (ThingRequest) returns (ThingResponse) {
  option (google.api.http) = {
    get: "/v1/{name=things/*}"
  };
};

The JsonTranscoding library handles this fine, and requests made to /v1/widgets/foo and /v1/things/bar are routed to the correct handlers. However when SwaggerGen runs, it throws a SwaggerGeneratorException exception

Expected Behavior

The ConflictingActionsResolver only lets me choose a single operation as the winner. This seems to run before the operation filters, as my filters never get called.

I think it would be incorrect to impose a pattern on the user (as these are clearly conflicted) but there should be some hook where I could disambiguate these two calls. Or a separate proto annotation that I could employ.

On a human level, I understand the intent behind these two, and could mutate the operations like /v1/{name=widgets/*} into /v1/widgets/{id} if given the opportunity.

Steps To Reproduce

Minimal Repo: https://github.com/adam8797/grpc-swagger-issue

Exceptions (if any)

SwaggerGeneratorException: Conflicting method/path combination "GET v1/{name}" for actions - ,. Actions require a unique method/path combination for Swagger/OpenAPI 3.0. Use ConflictingActionsResolver as a workaround 

.NET Version

10.0.100

Anything else?

I can see how it would be temping just to change the proto definitions, however in the project I'm working on we're attempting to follow the Google AIPs as close as is reasonable. I'd like to keep my proto files compliant, while having SwaggerGen allow me to inform it of the proper endpoints.

[adam8797]

Hey thanks for submitting a PR for this, but I think this might need a tad bit of discussion before they nail down a solution. To be honest I think the PR solves this particular issue, but I'm not sure its a great choice design wise. I believe its a breaking change.

The solution I was proposing was more along the lines of allowing the user to hook into the generation function, and knowingly override the behavior. I don't think the existing implementation in incorrect-- the route pattern is clearly /v1/{name} for both routes-- we just know it can be interpreted differently for JSON/HTTP clients.

I saw @JamesNK was added to the above PR, and I hope you'll forgive the summon, but I think this issue may need a little design consideration from a maintainer before we can really propose a solution.

Truth be told, I've been trying to get this repo to build on my machine for the past day (I've given up in frustration twice) but I'm happy to take a crack at a PR as well if you want to go a different route with it.