You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We just noticed that gnostic's proto-gen-openapi may create a wrong OpenAPI v3 spec when a message with identical name exists in an imported proto even though the messages belong to different packages. This happens although the message from the imported proto is not used at all in the base proto.
The generated API spec only includes HelloWorld from bar.proto (which is not used anywhere). I would expect it to include HelloWorld from foo.proto instead. Even using the fully-qualified name com.example.foo.HelloWorld in FooResponse does not fix this.
Setting option fq_schema_naming=true fixes it but I think even without this option proto-gen-openapi should not create a wrong specification. It should at least give a warning or throw an error when a message/schema name is ambiguous.
I imported openapiv3/annotations.proto which has a message named Contact (actually in openapiv3/OpenAPIv3.proto) to set option (openapi.v3.document). And this Contact is not used in my own foo.proto.
At the same time, Contact has been defined and used in foo.proto (package foo)
proto-gen-openapi unexpectedly treats foo.Contact as openapi.v3.Contact completely when fq_schema_naming=false.
zaakn
added a commit
to zaakn/gnostic
that referenced
this issue
Nov 9, 2023
We just noticed that gnostic's proto-gen-openapi may create a wrong OpenAPI v3 spec when a message with identical name exists in an imported proto even though the messages belong to different packages. This happens although the message from the imported proto is not used at all in the base proto.
Reproduction: https://github.com/n0v1/gnostic-gen-openapi-naming-issue-repro (see readme and proto files for details)
The generated API spec only includes
HelloWorld
frombar.proto
(which is not used anywhere). I would expect it to includeHelloWorld
fromfoo.proto
instead. Even using the fully-qualified namecom.example.foo.HelloWorld
inFooResponse
does not fix this.Setting option
fq_schema_naming=true
fixes it but I think even without this option proto-gen-openapi should not create a wrong specification. It should at least give a warning or throw an error when a message/schema name is ambiguous.Relates to issues #309 and #353.
The text was updated successfully, but these errors were encountered: