0

I have unidirectional (both client- and server-) streaming gRPC methods implemented in my golang server. I came across bufconn which enables me to creates my server via in-memory connections in my tests. However, I have logic in my method where I check the peer's address, it always returns "bufconn". I do rely on the peer to provide the IP address along with its port, but I can't really achieve that using bufconn.

  1. What is a canonical (or preferred) way to test gRPC streaming calls in golang?
  2. Is it considered an anti-pattern to rely on peer information in the context?
Bak
  • 3
  • 3
  • Can you just make up the addresses for testing? Your questions about testing streaming RPCs seem unrelated to using bufconn (streaming RPCs work fine over bufconn). – jdizzle Jun 13 '21 at 14:43
  • @jdizzle Yeah - streaming is unrelated, but just wanted to give broader context (and didn't know if bufconn was still the right way to test streaming RPCs). I did tried to make up an address like this: ``` p := &peer.Peer{ Addr: &net.TCPAddr{ IP: net.IPv4(1, 2, 3, 4), Port: 8888, }, } ctx := peer.NewContext(context.Background(), p) ``` but bufconn just returns `"bufconn"` no matter what: https://github.com/grpc/grpc-go/blob/master/test/bufconn/bufconn.go#L308 – Bak Jun 13 '21 at 21:21
  • You’ll have to hook in your own mechanism for getting the IP address under testing (create a custom XGetter interface that takes the connection?) – jdizzle Jun 14 '21 at 00:30
  • I see where you're going with it. As a golang newbie, may I ask you a quick snippet what it would look like? – Bak Jun 14 '21 at 14:25
  • i'm not sure what the code looks like now for getting the peer address. Maybe if you post it I can make some suggestions – jdizzle Jun 17 '21 at 17:14

0 Answers0