Response ordering must be guaranteered when streaming

[senconscious]

Describe the bug

Stream response process genserver prepends new responses when handling consume_response messages.
This disrupts ordering when stream is consumed by application slower than new responses arrive.

From docs:

Client streaming RPCs where the client writes a sequence of messages and sends them to the server, again using a provided stream. Once the client has finished writing the messages, it waits for the server to read them and return its response. Again gRPC guarantees message ordering within an individual RPC call.

To Reproduce
Run this simple test in test/grpc/client/adapters/mint/stream_response_process_test.exs under build_stream/1 describe block.

test "ordering bug", %{pid: pid} do
      hello_luis =
        <<0, 0, 0, 0, 12, 10, 10, 72, 101, 108, 108, 111, 32, 76, 117, 105, 115>>

      hello_luit =
        <<0, 0, 0, 0, 12, 10, 10, 72, 101, 108, 108, 111, 32, 76, 117, 105, 116>>

      stream = StreamResponseProcess.build_stream(pid)
      StreamResponseProcess.consume(pid, :data, hello_luis)
      StreamResponseProcess.consume(pid, :data, hello_luit)
      StreamResponseProcess.done(pid)

      expected_elements =
        [
          ok: %Helloworld.HelloReply{message: "Hello Luis", __unknown_fields__: []},
          ok: %Helloworld.HelloReply{message: "Hello Luit", __unknown_fields__: []}
        ]

      assert Enum.to_list(stream) == expected_elements
    end

Here we expecting that messages very ordered by server. Hello Luis is the first and Hello Luit - second. But order has been modified by Stream Response Server.

Expected behavior

Stream Response Process must save new responses in the same order as they've arrived

Logs

• N/A

Protos

• N/A

Versions:

• OS: Mac Sonoma
• Erlang: 26.1.2
• Elixir: 1.15.7-otp-26
• mix.lock(grpc, gun, cowboy, cowlib): (Doesn't matter)

Additional context
Attached demonstration pull request #396

[polvalente]

edit: Nervermind, I hadn't read the final sentence in the quote.

I'm not sure if the response ordering must be guaranteed.

For instance, 2 different packets might follow different network paths in the network layer, which might still cause messages to arrive out of order if one of the paths suddenly is slower than what was expected.

What's the problem that motivated this issue/PR?

[v0idpwn]

For instance, 2 different packets might follow different network paths in the network layer, which might still cause messages to arrive out of order if one of the paths suddenly is slower than what was expected.

This would be solved at TCP level, no?

[senconscious]

The problem I was trying to solve is to guarantee order for a bunch of records that are sent by another server.

Server 1: requests large amount of records
Server 2: sends large amount of records to Server 1 using GRPC.Server.send_reply/2 one by one.
Records streamed from database.

I can't fit whole data in the memory

As I understand it's a single RPC call, so by specs order must be guaranteed.

Packet ordering is a concern of a more low level network stuff (sorry for my english, OSI model, TCP layer).

[polvalente]

Yeah, I agree. I just left a comment in the PR regarding the data structure change. If there's a large number of messages this can become a significant problem. Other than that, we can move forward with this fix.