mirror of https://github.com/grpc/grpc.git
This documents a rule that's existed in a hard to find internal document that's existed since Feb 2016 by abhikumar@google.com. Since that rule is critical to untangling some gRPC C core behavior, we should document it publically.pull/10005/head
parent
437cc199ab
commit
8918aaeccd
2 changed files with 19 additions and 0 deletions
@ -0,0 +1,16 @@ |
|||||||
|
Ordering Status and Reads in the gRPC API |
||||||
|
----------------------------------------- |
||||||
|
|
||||||
|
Rules for implementors: |
||||||
|
1. Reads and Writes Must not succeed after Status has been delivered. |
||||||
|
2. OK Status is only delivered after all buffered messages are read. |
||||||
|
3. Reads May continue to succeed after a failing write. |
||||||
|
However, once a write fails, all subsequent writes Must fail, |
||||||
|
and similarly, once a read fails, all subsequent reads Must fail. |
||||||
|
4. When an error status is known to the library, if the user asks for status, |
||||||
|
the library Should discard messages received in the library but not delivered |
||||||
|
to the user and then deliver the status. If the user does not ask for status |
||||||
|
but continues reading, the library Should deliver buffered messages before |
||||||
|
delivering status. The library MAY choose to implement the stricter version |
||||||
|
where errors cause all buffered messages to be dropped, but this is not a |
||||||
|
requirement. |
Loading…
Reference in new issue