On this topic: https://pact-foundation.slack.com/archives/CLS16AVEE/p1684412631122329 We have a contract that has multiple interactions (say 2 sets of interactions) and these needs to run on some dependent pre-conditions. We set pre-conditions for set 1 and run those interactions using

--filter-state

for set 1 and the same thing for set 2. Why does the pactflow makes all interactions green check mark, if I run only set 1 interactions? Is that by design or a bug in pactflow? @Timothy Jones: Thanks for your response, I don’t see any relation mentioned anywhere in docs on

--filter-state

and

publish

. We should be able to publish partial interaction in a contract.

Why are you doing it this way? Can't you just use regular provider states

We should be able to publish partial interaction in a contract.

…why?

I'll try to add some context and maybe there is a better way of trying to achieve what we are trying to do. We have a provider that behaves differently depending on the hardware it is running on (these are embedded devices). If the device uses one chip one of the methods is not available and returns a

success: false

response. The consumer has two routes in the code, one that uses the method and gets the success response and one that uses the method and gets a failure response and then calls a different method instead. We have have a contract from the consumer with both the success response and the failure response. We are using provider state to capture whether or not we are expecting the method to be available. Now we want to verify this contract on the provider side. The contract needs to be verified against two devices with different chips so we are using the provider state filter to get all the interactions for the first chip and then publishing the results. We will then run the verification on the other device with the inverse filter so we can get all of the interactions verified. Basically, we want to be able to use provider state to know which chip to run the verification against. We also considered having different provider names for each hardware but seeing as the consumer just thinks of this as a single provider API then it would push the responsibility of knowing which responses come from which hardware to the consumers. Any advice on how best to approach this would be welcome.

Ah, neat. I’ll have a think about this- an interesting case

Not HTTP contract, its WebSockets. We have made a plugin to support this. Languages: C++ for both. We are currently exploring an option where we use a proxy to sit in front of the devices. The proxy will have a registry of the states which need to be sent to which device. We can then point the verifier at the proxy and use the state-change-url to tell the proxy which device it should be proxying to (hope that makes sense!). However, I am curious about this:

With Pact, I probably would write a script that:

• Runs one chip

• Runs the other chip

• Publishes verification success or failure

Are the verification results being written to a file by the pact-standalone-verifier, such that we can combine the results from each chip? I thought the results were being held in memory and just sent up at the end of the process. tbh I haven't looked into the mechanics of the verification result publishing at all yet.

This makes me nervous - how would you check that you have filtered the interactions correctly and not missed any?

It is a good question. We thought that if there were partial results then the contract would not be marked as verified until all interactions were green lit and therefore that would allow us to know that all interactions in a contract were verified and we hadn't missed any. Hopefully we will be moving towards a system where the provider has consistent behaviour across all chips that are supported. However this a way off unfortunately and until we have that we are going to have to be diligent in ensuring our tests are covering all the right things.

@Timothy Jones, @Matt (pactflow.io / pact-js / pact-go): For this use case, we logged partial interaction results to a file using

--json

option. The plan is to combine the results from from 2 partial interaction verifiers into one .json file and post to pactflow. Is there a way to post the .json verifier results to pactflow?

Yes, there probably is a way albeit it might be a bit awkward