On Mon, Mar 12, 2018 at 12:07 PM, Nathaniel Manista <nathan...@google.com>
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 grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
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.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to