We may need to remove the "grpc-trace-bin" trace header from the GRFC and wait until the census interaction with gRPC is more clearly defined. There may be different spans representing the client process, the stream, and the server process. There's no single consistent behavior across languages today. Retries and hedging add further complexity to the picture because they are stream level concepts, so if each stream has different trace spans then the higher level interceptors will not be able to see them. One reasonable approach is to log the client process span when a client RPC begins, log the server process span when a server RPC begins. But this is creeping outside the scope of the binlog proto.
On Wed, Aug 29, 2018 at 5:15 PM Spencer Fang <[email protected]> wrote: > > > On Wed, Aug 29, 2018 at 4:28 PM yashkt via grpc.io < > [email protected]> wrote: > >> >> On Tuesday, August 28, 2018 at 8:18:14 PM UTC-7, Spencer Fang wrote: >>> >>> Responses inline: >>> >>> On Tue, Aug 28, 2018 at 6:25 PM yashkt via grpc.io < >>> [email protected]> wrote: >>> >>>> Also, this doc might be outdated but it does say that server can cancel >>>> RPCs https://grpc.io/docs/guides/concepts.html#cancelling-rpcs >>>> >>> I think C is the only implementation with a server side API that allows >>> this. Since the proposal allows logging a C server side cancel in a >>> sensible way, I think we can add a comment about this possibility but do >>> not attempt to log the server cancellation attempt. >>> >> If the gRPC guidelines allow a server to cancel, then why not log the >> cancellation attempt? >> > > Outcome of offline discussion: server cancellations are not considered a > part of the semantics at the moment, so let's not log the server's > initiation of the cancellation. > > >>>>> 1. The client can initiate a Cancel but still receive the status >>>>> from the server before the Cancel actually takes affect. >>>>> - In this case, implementations should log the server trailers >>>>> since that is how the RPC actually ended. >>>>> >>>>> According to the (yet to be merged) gRPC call semantics >>> <https://github.com/grpc/grpc/pull/15460/files>, when a CANCEL >>> happens: "inbound and outbound buffered data should be cleared. >>> Cancellation trumps graceful completion; if the client gRPC implementation >>> received the Trailers before the cancellation, yet the client application >>> has not received the Trailers, then cancellation generally should win." I >>> agree that if the implementation sees trailers it is fine to log them, but >>> the implementation is not required to use the received status to end the >>> RPC. >>> >> This would depend highly on where the binary logging implementation is in >> the stack. If it is closer to the application (which is what we want), the >> binary logging implementation would log the status with which the RPC ended >> as seen by the application. >> > > I agree that we should log only the status given to the client > application. I was just saying the client library can choose how to break a > tie if there's a race and it was aware of both the client initiated > cancellation and the incoming status. If what you meant by "since that is > how the RPC actually ended" is "that is what the client application saw" > then we are in total agreement. > > -- > Spencer Fang > > -- Spencer Fang -- 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAK%3D-x_6sQ_ehibtciD7kvQB1_AENB1FuzRpHwRH8_94KwBM6Ew%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
