While talking with Craig on Friday, we realized that we need to make the wire protocol a bit stricter in order to implement retries.
Currently, the spec allows status to be sent either as part of initial metadata or trailing metadata. However, as per the When Retries are Valid <https://github.com/ncteisen/proposal/blob/75e08fa10405430e8177cfd91bf63a25ff4ad617/A6.md#when-retries-are-valid> section of the gRFC, an RFC becomes committed when "the client receives a non-error response (either an explicit OK status or any response message) from the server". This means that in a case where the server sends a retryable status, if the status is not included in the initial metadata, the client will consider the RPC committed as soon as it receives the initial metadata, even if the only thing sent after that is the trailing metadata that includes the status. Thus, we need to require that whenever the server sends status without sending any messages, the server should include the status in the initial metadata (and then close the stream without bothering to send trailing metadata) instead of sending both initial metadata and then trailing metadata. Noah, can you please add a note about this to the gRFC? Based on a previously encounted interop problem (see https://github.com/markdroth/grpc/pull/3, which was included in https://github.com/grpc/grpc/pull/7201), I believe that grpc-go already does the right thing here (although Saila and Menghan should confirm that). However, since that previously encountered problem did not show up with Java or C++, I suspect that those stacks do not do the right thing here. Craig has confirmed that C-core needs to be fixed in this regard, and I've filed https://github.com/grpc/grpc/issues/9883 for that change. Eric and Penn, can you confirm that Java will need to be changed? I'm hoping that this isn't too invasive of a change, but please let us know if you foresee any problems. Please let me know if anyone has any questions or problems with any of this. Thanks! On Fri, Feb 10, 2017 at 4:31 PM, ncteisen via grpc.io < [email protected]> wrote: > I've created a gRFC describing the design and implementation plan for gRPC > Retries. > > Take a look at the gRPC on Github > <https://github.com/grpc/proposal/pull/12>. > > -- > 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/30e29cbc-439c-46c4-b54f-6e97637a0735%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/30e29cbc-439c-46c4-b54f-6e97637a0735%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Mark D. Roth <[email protected]> Software Engineer Google, Inc. -- 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/CAJgPXp5CVHxpxYQ2DMmn-xqb9H6JGt%3Diye8mvjNxKswMXk3RUQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
