Hello, I'm testing a service (

users-service

) which is both an API provider and a API consumer. The provider test works

CONSUMER           | C.VERSION                                  | PROVIDER      | P.VERSION                                     | SUCCESS? | RESULT#
-------------------|--------------------------------------------|---------------|-----------------------------------------------|----------|--------
gdprexport-service | C-5cf6a5f1b2e171382a3f0dee4e8696d8a0c34685 | users-service | P-v2-f1e31679d8f7a7c144ca63d80a5ebf69ac92719d | true     | 1

But for some reason an the

gdprexport-service

, which is the API consumer, is also tested against the

users-service

consumer pact 🤯

CONSUMER           | C.VERSION                                  | PROVIDER      | P.VERSION | SUCCESS? | RESULT#
-------------------|--------------------------------------------|---------------|-----------|----------|--------
gdprexport-service | C-5cf6a5f1b2e171382a3f0dee4e8696d8a0c34685 | users-service | ???       | ???      |        
users-service      | C-f1e31679d8f7a7c144ca63d80a5ebf69ac92719d | accounts-api  | 6.5.2     | true     | 1

There is no verified pact between the latest version of gdprexport-service (C-5cf6a5f1b2e171382a3f0dee4e8696d8a0c34685) and version C-f1e31679d8f7a7c144ca63d80a5ebf69ac92719d of users-service

We prefix the consumer version with

C-

and the provider version with

P-<api-version>

. Actually pactflow should only test

gdprexport-service | C-5cf6a5f1b2e171382a3f0dee4e8696d8a0c34685 | users-service | P-v2-f1e31679d8f7a7c144ca63d80a5ebf69ac92719d 
users-service      | C-f1e31679d8f7a7c144ca63d80a5ebf69ac92719d | accounts-api  | 6.5.2

and not

gdprexport-service | C-5cf6a5f1b2e171382a3f0dee4e8696d8a0c34685 | users-service | ???

How can I fix this?

Hi @Thomas, could you try identifying the pacticipants as

users-service-consumer

when it is a consumer and

users-service-provider

when it is a provider?

Didn't thought about this option so far, but I can give it a try.

I don't know the exact logic that Pactflow users to determine whether some pacticipant is a consumer or a provider, maybe it's all in one big list / table 🙂 The core maintainers can probably tell you more about that. The different

c-

and

p-

versions should not be the problem, you can use pretty much whatever you want as a provider or consumer version identifier (although there are some good practices)

The logic should only be "does this pacticipant send requests or receive requests?" (i.e. just the directionality of requests, which is typically one-way per contract)

You shouldn’t need to identify different parts of the same app as consumer vs provider. That would make some things hard to reconcile (like the pacticipants dependency graph, and maybe preverification). (edited)

yes, why are you doing this? It doesn’t make sense (at least without further explanation) for a version of the software to be a consumer and another version of the software to be a provider. Either it is both, or it isn’t, and the version is orthogonal to that

Thank you for your answers. So far I didn't change the pacticipant-name. Any other suggestions?

It would help if you explain your setup in a diagram. In fact, the network diagram in PactFlow would help to see what’s happening

This diagram has

rt-

prexfies on the apps - did you manually modify the output from above to drop that?

what do you mean by this?

@Matt (pactflow.io / pact-js / pact-go) I referred to the first suggestion from @Bas Dijkstra

Can you please show the arguments you used to generate this?

if [ "$(params.publish-consumer-contract)" = "true" ] ; then
          if [ -n "$(params.pact_deploy_to_environment)" ] ; then
            pact-broker can-i-deploy\
             --broker-base-url=$(params.pact_broker_base_url)\
             --broker-token=$PACT_BROKER_TOKEN\
             --pacticipant=$(params.pact_pacticipant)\
             --version=C-$(params.git_sha)\
             --to-environment=$(params.pact_deploy_to_environment)\
             --retry-while-unknown=2\
             --retry-interval=10
          else
            pact-broker can-i-deploy\
             --broker-base-url=$(params.pact_broker_base_url)\
             --broker-token=$PACT_BROKER_TOKEN\
             --pacticipant=$(params.pact_pacticipant)\
             --version=C-$(params.git_sha)\
             --retry-while-unknown=2\
             --retry-interval=10
          fi
        else

Currently we are not setting the

to-environment

(we are on it).

This row says

gdprexport-service

can’t be deployed (to wherever the target you specified is) because the

users-service

is required for it to operate.

CONSUMER           | C.VERSION                                  | PROVIDER      | P.VERSION | SUCCESS? | RESULT#
-------------------|--------------------------------------------|---------------|-----------|----------|--------
gdprexport-service | C-5cf6a5f1b2e171382a3f0dee4e8696d8a0c34685 | users-service | ???       | ???      |

It goes on to say:

There is no verified pact between the latest version of gdprexport-service (C-5cf6a5f1b2e171382a3f0dee4e8696d8a0c34685) and version C-f1e31679d8f7a7c144ca63d80a5ebf69ac92719d of users-service

I think you are confused by versioning. The version is the piece of software you’re releasing (e.g. git sha a1b2c3). If

users-service

is both a consumer and a provider, then it should only have one version. Because when you deploy it, you only deploy one version of it. I suspect this is why it’s picking up the

C-

version. The last time

users-service

is deployed to <target>, it was the version with

C-

. I think that is causing some confusion about how all of this works.

We came up with this, because the services offers different (legacy, but still active) API versions. Currently we are testing the provider against API version 2 ->

P-V2-<git-sha>

. I think using only the

<git-sha>

as version lead pactflow test the consumer against all APIs, where of course only one test succeeded, but I can't remember exactly. Is your recommendation to use the

<git-sha>

without prefix for both consumer and provider and for all API versions?

Yes, that would be my recommendation. If the API is versioned and logically different, you could: 1. Use the

releases

to model that two concurrent released versions in the wild (see https://docs.pact.io/pact_broker/recording_deployments_and_releases#releases) 2. Create a new name of the API to indicate it’s a separately deployed thing (e.g.

users-service-v2

) It sounds like it’s the same deployable unit that supports multiple interfaces (API versions), so I don’t think these actually make sense for you.

OK, I'll have a look into that. Thank you.

You would need to merge them into a single document, PactFlow doesn’t currently support multiple documents (as you only upload one, so references aren’t involved) In your instance, its trying to overwrite the contents of the file, which it’s saying is dangerous (quite rightly) as that contract content, against that version would be non deterministic. Also on can-i-deploy, using just the version, is essentially checking against the latest published contracts for related parties, which is really underministic too. Without envs/releases, I would use can I deploy to the main branch.

You would need to merge them into a single document

Oh, boy. Didn't know that only one file is supported. I was aware, that it should not include references etc, but I thought we can upload multiple files.