grpc python streaming response order

[rvsh...@gmail.com]

I was trying out python server streaming, and it is unclear to me if there is a guarantee that the client will receive all messages the server sent. I have a test setup here https://github.com/rvshah825/grpc-python/tree/5f306d820458b539187a6c7fa80f7d3e7d2bed87 (client.py, server.py)

The setup is that the client opens a stream request to server, and the server returns a value then aborts the call. It seems that if I wait a second on client before looking for replies on the stream, I never seen the initial value, and instead only get abort.

The reason I am opening in forum rather than as bug on tracker is that it is unclear to me what is the expected behavior. Naively, I would assume that if I consume the stream response in client calling `next` repeatedly will give me the results that the server sent in order. I would consider aborting to be a value, so in this test I assume that the stream of values from server is [Response, Abort]. What is a little ambiguous is that since the server is sending replies without waiting for requests from client, maybe I cannot expect this?

Platform I am testing on if relevant is:

```

(grpc110) vagrant@vagrant:/vagrant$ python
Python 3.6.4 (default, Jan 28 2018, 17:52:01)

(grpc110) vagrant@vagrant:/vagrant$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.3 LTS
Release:        16.04
Codename:       xenial
(grpc110) vagrant@vagrant:/vagrant$ pip list
DEPRECATION: The default format will switch to columns in the future. You can use --format=(legacy|columns) (or define a format=(legacy|columns) in your pip.conf under the [list] section) to disable this warning.
grpcio (1.10.0)
grpcio-tools (1.10.0)
pip (9.0.3)
protobuf (3.5.2.post1)
setuptools (39.0.1)
six (1.11.0)
wheel (0.30.0)

```

[Nathaniel Manista]

On Fri, Mar 23, 2018 at 4:48 AM, <rvsh...@gmail.com> wrote:

I was trying out python server streaming, and it is unclear to me if there is a guarantee that the client will receive all messages the server sent.

It is guaranteed if the status code of the RPC is OK. If the RPC terminates with any non-OK status, it is not guaranteed that the client will see all messages sent by the server.

I have a test setup here https://github.com/rvshah825/grpc-python/tree/5f306d820458b539187a6c7fa80f7d3e7d2bed87 (client.py, server.py)

The setup is that the client opens a stream request to server, and the server returns a value then aborts the call. It seems that if I wait a second on client before looking for replies on the stream, I never seen the initial value, and instead only get abort.

The reason I am opening in forum rather than as bug on tracker is that it is unclear to me what is the expected behavior.

As it happens we're a little unclear ourselves.

Naively, I would assume that if I consume the stream response in client calling `next` repeatedly will give me the results that the server sent in order. I would consider aborting to be a value, so in this test I assume that the stream of values from server is [Response, Abort]. What is a little ambiguous is that since the server is sending replies without waiting for requests from client, maybe I cannot expect this?

The currently-supported behavior is that service-side abortion of an RPC (terminating an RPC with any status code other than OK) has "drop everything on the floor" semantics. The abortion renders the response message semantically meaningless, so the server-side gRPC runtime will not bother sending it if it hasn't already done so, and upon learning of the RPC abortion, the invocation-side gRPC runtime will not bother delivering the response (if it even received it) to the local application.

Platform I am testing on if relevant is:

```

(grpc110) vagrant@vagrant:/vagrant$ python
Python 3.6.4 (default, Jan 28 2018, 17:52:01)

(grpc110) vagrant@vagrant:/vagrant$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.3 LTS
Release:        16.04
Codename:       xenial
(grpc110) vagrant@vagrant:/vagrant$ pip list
DEPRECATION: The default format will switch to columns in the future. You can use --format=(legacy|columns) (or define a format=(legacy|columns) in your pip.conf under the [list] section) to disable this warning.
grpcio (1.10.0)
grpcio-tools (1.10.0)
pip (9.0.3)
protobuf (3.5.2.post1)
setuptools (39.0.1)
six (1.11.0)
wheel (0.30.0)

I don't think it's relevant in this particular case, but thank you for including these details!

-Nathaniel