This is the golang version of this bug in the rust implementation: containerd/ttrpc-rust#169

If a client makes a request to a server streaming RPC (eg: rpc DivideStream(Sum) returns (stream Part);) using a default request (eg: streaming.Sum{}), the call hangs indefinitely. This can easily be observed by modifying the streaming_test, to send an empty Sum.

The root cause is twofold:

1. Empty / Default proto messages serialize to a length of zero
2. The services implementation does not attempt to deliver an empty payload (I think because it assumes it will be receiving DATA messages soon, but the client sends only the request).

The protocol doesn't clearly specify the behaviour of empty payloads on requests. However, based on the Data semantics:

Since ttrpc normally transmits a single object per message, a zero length data message may be interpreted as an empty object. For example, transmitting the number zero as a protobuf message ends up with a data length of zero, but the message is still considered data and should be processed.

It seems to me, for consistency's sake, the same behaviour should apply to an empty payload on a Request as well.