On Mon, Mar 12, 2018 at 12:07 PM, Nathaniel Manista <[email protected]> wrote:
> There's not a whole lot of documentation around the proposed feature, > because it's not so much a new feature as much as filling in a missing > corner. Consider a two-by-two matrix of "have read all requests/have not > read all requests" and "respond with not-OK status/respond with OK status". > It is currently the case that a service-side application: > > 1) after having read all requests can respond with not-OK status, > 2) after having read all requests can respond with OK status, > 3) without having read all requests can respond with not-OK status, > 4) without having read all requests *cannot* respond with OK status. > > So there's not a whole lot of documentation needed to say "this fourth > case should be made to work like the other three". > Aww fiddlesticks: I really liked this explanation of the behavior to be changed but it turns out that a gRPC team member implemented Early OK last December and failed to update the bug about it <https://github.com/grpc/grpc/issues/7032>. The idea has been removed from our ideas page <https://github.com/grpc/grpc/pull/14687>. My apologies! -Nathaniel -- 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/CAEOYnASJqK-g%3DAP2msVgj%3DghhccXhxH1ZAjopMQsdeefBOtKOw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
