Hi All. I am looking for some examples for pact contract testing gRPC bi-directional streaming services. Can you please advise if this is supported at the moment? if yes, can you please point me to some examples? Thanks!

@uglyog I actually have forgotten how we support this, if we do. Would we recommend people create two separate tests? One for the consumer initiated request and another for provider initiated? IIUC streaming is really just an open pipe where consumers/providers can communicate. It doesn’t imply a given / when / then scenario.

I haven't really thought through what bi-directional streaming means in a Pact context. My assumption was that it can be reduced to a few Pact tests for the different types of messages, as streaming is just a transport concern. I was waiting for some examples of how people would use this. If we look at bi-directional streaming in general (not gRPC specific), I think there would be a couple of different use cases: 1. 1-1: (I assume this is the general case) the requests and responses are sent as required, but they are correlated. I.e. As users need to be provisioned , the consumer sends a ProvisionUserMessage (there can be multiple of theses at any time), and when the work is done, the provider sends back ProvisionedUserStatus messages. I can see a single Pact test needed to test a correctly formed ProvisionUserMessage results in a correctly formed ProvisionedUserStatus message. 2. 1-n: the consumer can send any number of messages, but each one is correlated to a number of response messages. I guess a query for documents would be this type of interaction. Again a single Pact test is needed here. 3. n-m: This is one I'm unsure of. The consumer can send a number of messages, and each group is correlated to a number of response messages. We don't support this type of interaction. 4. n/m: Again, I'm unsure if anyone will use this option. The consumer sends messages as needed, and the provider sends messages as needed, and there is no correlation. I.e. consumer sends events to provider, and provider sends events to consumer. These can probably just be reduced to two async message Pact tests, one for C -> P and one for P -> C

That’s helpful context, thanks Ron

thanks for the inputs @uglyog and @Matt (pactflow.io / pact-js / pact-go). I think our use case falls under

1-n

category specified above. On every consumer request message, server sends a bunch of correlated messages.