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