-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to specify empty response schema #2884
Comments
Have you tried using |
I had a look at the spec, and I agree that it should be possible to set this to something empty given this definition of the field: However, with the way that we specify responses using the annotations, how would we tell the difference between an empty response and a response that's not been set at all? The message definition is here: https://buf.build/grpc-ecosystem/grpc-gateway/file/main:protoc-gen-openapiv2/options/openapiv2.proto#L230. Setting this to |
Hey, BTW, buf links are not permanent (https://buf.build/grpc-ecosystem/grpc-gateway/file/main:protoc-gen-openapiv2/options/openapiv2.proto#L230) But if we meant this:
Can't we change However I understand that (https://google.aip.dev/180#moving-into-oneofs):
And optional=oneof |
I'd be worried about making a change like that to a type that's so central to all our annotations, and I'm not convinced it would make a difference either. If we can already set it to |
In this case, this is a breaking change, but however I think it's fine since I guess no one is using those annotations outside of grpc-gateway Go generated files - so I guess that the blast radius is confined. To be honest, this example is a microcosmos of actual grpc trancoding challanges (since we want our annotation protobuf to have the same structure as the schema json): Since in json files you can specify the absence of the field as another state, but protobuf tooling auto generates empty classes/structs in all languages even if they are missing from the wire. Back to the task at hand, |
Would |
Actually this is going too strong in the other direction. I think there are two ways to solve the issue in a more reasonable way:
To be honest I'm also not so sure about if it's okay to document that an API call does not return content, when in practice it does, this is a limitation of gRPC transcoding. We can feature-flag option 2 under |
I think we already have a special case for |
I guess that's actually accurate per the behavior of the JSON marshaler, so maybe there's not much we can do there. |
Yea
It's just for optics mainly |
🐛 Bug Report
Response schema states that
however when i omit schema from rpc response defenition it still renders as
"schema": {}
inapi.swagger.json
which in editor rendered asTo Reproduce
Define RPC with empty schema response option
Expected behavior
schema
key not renders inapi.swagger.json
and rendered schema looks likeThe text was updated successfully, but these errors were encountered: