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 -- 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_4Om4eycxdWS8xM-bRCkOdeK4hZh%2BkFCvp9eeM8CGwRvg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
