Open lachlancooper opened 2 years ago
Hi, thanks for your issue! I'm surprised we didn't already have an issue for this, I agree that it makes sense to automatically apply this. Furthermore, if both an annotation and a protobuf level option is set, the annotation should take precedence (so that it's always possible to change the output of the openapi generator without changing the protobuf definition).
@johanbrandhorst i think that this annotation should also add some context value to indicate that the method is deprecated. Having this, we can use an interceptor to collect a metric and notify clients about new implementation. What do you think?
I don't think that should be necessary - with APIv2 it should be possible to tell already through reflection whether a method is deprecated. I would consider this ask outside the scope of the gateway.
can you please assign this issue to me ?
Please just submit a PR if you want to work on this
🚀 Feature
When generating an openapiv2 definition, any protobuf
deprecated
field options are currently ignored. It would be nice if the generator automatically set the deprecated field on the resulting parameter object accordingly.Note that the deprecated field on operation objects is already supported, though this is handled through a custom annotation instead of the official
deprecated
option. This was already touched on in #2856, but in my opinion it makes sense to support the official option (deprecated = true
can be set onrpc
,message
,enum
, andfield
) wherever possible instead of requiring the use of custom annotations.