Hi there! I've come across an issue (that is well described by this issue <https://github.com/grpc/grpc/issues/15966>) that is impacting my usage of gRPC with ruby and I'm now working on a PR to fix the problem. To summarize - the ruby interceptor proposa <https://github.com/grpc/proposal/blob/master/L11-ruby-interceptors.md#server-interceptors>l indicates that gRPC responses may be accessed/modified within an interceptor, when neither is true currently (as described in the linked issue). There's also a relevant comment <https://github.com/grpc/grpc/pull/12100#discussion_r190475501> on the implementing PR indicating why this may be the case. gRPC interceptors in other languages work this way - allowing responses to be inspected/modified. Without this functionality, ruby gRPC interceptors only currently provide half the functionality as interceptors in other languages.
I've started working on a solution, and would like to solicit some suggestions for the approach. I noticed that there is no top level object describing the gRPC response. It seems the ruby version of the protobuf response is returned from this call here <https://github.com/grpc/grpc/blob/1eedf84ad5a1f63c996f2897e58579cdd5dfca9d/src/ruby/lib/grpc/generic/rpc_desc.rb#L60> and then here <https://github.com/grpc/grpc/blob/master/src/ruby/lib/grpc/generic/active_call.rb#L235> a collection of grpc_ops is generated and sent to run_batch <https://www.rubydoc.info/gems/grpc/0.11.0/GRPC%2FCore%2FCall:run_batch>. It seems in order to allow interceptors access to the response, the items composing the ops will need to be wrapped in some sort of structure. I'm also anticipating that instead of calling active_call.server_unary_response <http://active_call.server_unary_response(> within the block passed to the interceptors, we can instead get the response from the inter_ctx.intercept! call (since interceptors will now need to return the response), and then invoke the actual network response instead, allowing any interceptor in the chain to make modifications or inspect the response, before it is sent. My questions are: 1) is this approach reasonable? 2) where would a gRPC response class fit in well? is there anything it needs besides payload, status, and metadata? Any thoughts on naming? Thanks, Michelle -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/23d24b66-6608-47bd-8d23-62600dd6aa64n%40googlegroups.com.
