Closing one sending direction can leave useful work in the other

In gRPC over HTTP/2, each application message has a one-byte compression flag and four-byte message length before its message data. The length describes the encoded message data carried in that message, including compression when selected; decompressed size needs a separate bound. These message boundaries need not align with DATA frames or network reads. A streaming decoder retains partial headers and bodies just like any incremental parser. Receiving one complete message does not mean the request direction has ended, and receiving the end of that direction does not imply that the response direction has delivered final status.

A client's half-close signals that it will send no more request messages. The server can continue reading already sent data and can send responses or a final result, depending on the RPC's declared streaming shape. Cancellation instead asks to terminate the call and stop useful work; it can still race with side effects. A server's final status ends the RPC's response lifecycle, while a transport error can prevent normal status delivery. Keep these events visible in logs and ownership rules so resource cleanup follows the actual API contract rather than assuming that a completed write means the remote application consumed it.

Flow control prevents a sender from indefinitely overrunning a receiver's available capacity, but it does not automatically bound every application queue before the transport. An application that enqueues messages faster than the RPC writer accepts them can retain unbounded memory locally unless it imposes its own limit. A successful asynchronous write may mean the framework accepted work, not that the peer processed or durably stored it. Document when a buffer can be reused, when cancellation releases ownership, and whether multiple simultaneous reads or writes are permitted by the chosen runtime's streaming API.

Two endpoints can deadlock if both synchronously write enough to exhaust receive credit while neither reads. Each waits for permission that the other would create only by consuming data. The remedy is a protocol and execution design that allows required reading, bounded production, and control progress, not a promise that larger buffers will handle every stream. Some methods intentionally send all input before producing output, while others require concurrent bidirectional progress. Establish that sequencing contract explicitly. Include cancellation and deadlines so a failed peer or broken application dependency cannot retain the stream and its buffers indefinitely.

Exercise an empty input stream, a half-close after several messages, a server response before client completion where the method permits it, cancellation during a partial message, and transport failure before final status. Verify which messages are considered accepted, which business effects need reconciliation, and which resources are released. A count of sent messages is not an acknowledgment protocol; add sequence or operation identifiers if the application needs restartable delivery evidence. Retrying an entire interrupted stream may replay earlier effects unless the method's semantics or a deduplication mechanism explicitly makes that safe.

The queue lab illustrates consumption pressure rather than directional state. For each fresh run Reset, explicitly set BOTH rates, predict, then Play or Step: compare (λ,μ)=(4,3) with (2,3). Both start with four units at t=0; one grows and the other drains by four seconds. Rate edits retain elapsed t and recompute from four, so they do not model a half-close event midway through a run. There are no message envelopes, two-way states, cancellation, or final statuses. Use the worked message ledger to count bytes, and a separate state trace to decide which direction remains open.