Hi everyone! I'm not sure if this is the channel to ask this question, but here we go. I'm trying to use providers states to create an entity and then test the contract of a

get

endpoint for that entity. I need to create it first so that the endpoint doesn't return a 404. I have created a provider state setup function in my API, that creates this entity and returns a dictionary with the relevant value for the generator. I am using the docker pact-cli for verifying the provider, and it is calling that endpoint correctly. My issue is that it is not modifying the pact to use the returned id instead of the example specified in the pact. Here's an example of my code:

// Consumer in JavaScript
provider
      .given("an existing experiment")
      .uponReceiving("a request to get the experiment")
      .withRequest({
        method: "GET",
        path: fromProviderState("/v3/experiments/${uuid}", `/v3/experiments/${exampleUuid}`),
      })
      .willRespondWith({
        status: 200,
        body: { resource: like({
                 uuid: fromProviderState("${uuid}, exampleUuid)
              })},
      }));

# Provider state setup endpoint (Python & FastApi)
@router.get(/pact/setup)
def pact_setup():
    experiment = create_experiment()
    return { "uuid": experiment.uuid }

The setup function is being called by the docker verifier, returning the uuid of the created experiment, but the provider verification is still executing a get request to the

exampleUuid

. Is there anything I'm missing?

Hi, apologies for cross-posting from #C9WTB2JDV, but just in case that channel isn’t monitored.

Hi, I think there is a serious issue with

eachKeyLike()

and it might have to do with the fix here: https://github.com/pact-foundation/pact-reference/issues/216 Please see my comment here https://github.com/pact-foundation/pact-reference/issues/216#issuecomment-1480976176 and the added note below: https://github.com/pact-foundation/pact-reference/issues/216#issuecomment-1480996968 I ran the same on Windows and Mac as I wasn't sure if it is related to my machine. But I got the same result. This is a simplified version to show the issue. I have a more complex data-structure I want to test and the resulting

matchingRules

I got were looking very strange: Example:

"$.angebote.*.*.*[*].*[*].*.*.*": {
  "combine": "AND",
  "matchers": [
    {
      "match": "type",
      "min": 1
    },
    {
      "match": "type"
    },
    {
      "match": "integer"
    }
  ]
},

How could anything satisfy that.

blobwave Hey everyone, hope you are doing well today! The latest Pact blog is out. So sit back, relax, and join me for some contract testing in the wild. Hear from community experts and some of the latest initiatives in the Pact ecosystem. You can read it here!

Hello, So one of the questions I have received is.

can contract tests ensure the understanding of what is an optional parameter and what is not between provider and consumer (and how)

Hello, I've been using PACT for HTTP contracts, and it's great. I have some questions regarding its usage with message contracts: - I've noticed that the documentation does not provide a full scenario example of how to write and validate a contract for message target as it does for HTTP ones, does this have any implication on the future development targeted for the message contracts, or is it just not mature enough? - When verifying HTTP contracts, PACT tests the contracts against the controller at the exposed port by the provider. However, for the message contracts, it is as simple as manually building the message object and returning it in a method, which does not really tests the correctness of the provider, since it can be returning a different object than the one being used in reality. Are there any future plans or vision to change this?

So, I came here from https://docs.pact.io/faq/convinceme .. I am still yet not convinced, because of our current workflow is 180deg different on what pact offer that is Consumer-Driven. But "I have control over the consumer", this mostly internal apps afterall. so 1. Will consumer now dictate the provider endpoint and response ? 2. Then each of my consumer now will write basically some 80% identical tests because most of them require the same response from the same endpoint ?

Hi there. I try to convince my Team, but the argument is still: We use yaml files and an API generator, so what is the real advantage of Pact? For sure, prevent breaking changes! I know that YAML Files still dont prevent Integration Bugs from happening, but what bugs exactly are meant here?

👋 Hi all, apologies if this seems spammy, we just need your help to spread the word 🙂

Hi All. I have a question on the pact broker config. Everything works fine if I have this annotation used on the provider verification test class. @PactBroker(scheme = "https", host = "company.test.stp.hmlr.zone", port = "443"). But if I changed it to @PactBroker and add config on my build.gradle.

pact {
    broker {
        pactBrokerUrl = '<https://company.test.stp.hmlr.zone/>'
    }

the pact broker won't be found. Not sure why it does not work. Please help. Thank you.

is anybody doing contract testing against graphql endpoints?

it's all http with funky protocol inside, sure, but I'm curious about things like provider states (IDs, etc.)

google does return a few hits (mostly blogs posts with a simple request/response pair that are fairly static), so I'm still wondering

Hi all! Sorry, has contract testing to be made at same language of solution side?

I've just noticed that our consumer contracts are being committed to version control. This seems like a bad idea -- when someone deletes or renames a contract, since the change is merged to the contract file, we never get rid of the old contract. I took a look through the docs and can't find anything about this one way or the other (I might have missed something though!) so I just wanted to ask here before I remove them from version control, to make sure I'm not doing something silly . . .

Hello, I was attempting to debug a contract between two of my services in order to replicate a build issue I was having at the time and one of the steps to do so was to delete the PACTs between them. Now when I run my consumer contract tests, it seems to be using a version of the contract which is supposed to have either been updated or deleted despite the UI showing that this contract does not exist. Does anyone know what's going on with that and how to resolve it? (resolved see reply)

Hi all! Im having an issue with pact integration that i wasn't having before, suddenly this error appeared and configuration on provider test seems correct so i don't know why its not getting the pact from pactflow

<http://au.com|au.com>.dius.pact.provider.junitsupport.loader.NoPactsFoundException: No Pact files were found to verify

Provider: pss-paymentMethod-api

Source: Pact Broker <https://adidascdc.pactflow.io>

Hello, I would like your opinion about this use case: We have a provider service that exposes one POST endpoint, let’s say

/makePayment

That endpoint takes in two input parameters i.e, _payment_token_ and _customer_id_ Whenever consumer service hits that endpoint, provider internally calls a third party service(external vendor) to make the payment based on payment token and customer id. And returns the response accordingly. The catch is that each payment_token can be used only once. And 3rd party service doesn’t provide a dummy/static token, and there exists a way to call an endpoint in 3rd party staging env to generate the token. My point is that while generating the contract tests in consumer side, we don’t know have payment_token. So, how should I approach this problem? One way I could think is to mock 3rd party service in provider side and carry out the tests. However, if I would like to avoid mocking and want to call staging env of 3rd party service from provider service, then is it feasible to carry out contract testing?

I've just released the latest episode of my podcast. A conversation on OpenAPI specifications: https://www.pactman.co.uk/contract-testing-podcast/episode/1bbcff5c/openapi-specification-with-tobias-muller

This message was deleted.

Anyone using webhookless workflows out in the wild?

hey peeps, I was able to use the pact-provider-verifier for a while now, but this week I had to go through a DELETE endpoint and I notice that things on the provider side froze and I couldn’t see any result. Did anyone see this issue before and know how can I avoid it? This DELETE request has a body on it. I read a little on the matter and I saw this open issue: https://github.com/pact-foundation/pact-js/issues/484 Considering that I am using the agnostic implementation of the provider, is there anything I could do?

Hi my CI is having the following error when I am using the

pactfoundation/pact-cli:latest

docker image

/usr/lib/ruby/gems/3.1.0/gems/pact_broker-client-1.66.1/lib/pact_broker/client/hal/http_client.rb:49:in `create_request': undefined method `request_uri' for #<URI::Generic //pact.dev.stackjourney.xyz/contracts/publish> (NoMethodError)
 
          request = Net::HTTP.const_get(http_method).new(uri.request_uri)
                                                            ^^^^^^^^^^^^

I have searched through all issues in the pact foundation github space this is the docker command I used

docker run -t -i --rm --init --volume .. --env PACT_BROKER_BASE_URL --env PACT_BROKER_USERNAME --env PACT_BROKER_PASSWORD --env GIT_BRANCH=gz/FEAT-69/brokerclient/1 pactfoundation/pact-cli:latest /bin/sh -e -c $'pact-broker help\npact-broker publish backend/pacts --tag-with-git-branch'

Hi I noticed on my API the pact verifier is making two sets of requests to run one test:

2023-04-18 10:44:07  "POST /_pact/provider_states HTTP/1.1" 200 4 "-" "Faraday v1.10.3"
2023-04-18 10:44:07  [INFO] base.py(270): POST <http://elasticsearch:9200/battery.notification*/_search> [status:200 request:0.024s]
2023-04-18 10:44:07  "GET /battery-notifications?limit=100&offset=0&id=36baa499-ce79-4c03-96e3-93a90fb7f1d9 HTTP/1.1" 200 309 "-" "-"
2023-04-18 10:44:28  "POST /_pact/provider_states HTTP/1.1" 200 47 "-" "Faraday v1.10.3"
2023-04-18 10:44:30  [INFO] base.py(270): POST <http://elasticsearch:9200/battery.notification*/_search> [status:200 request:0.047s]
2023-04-18 10:44:30  "GET /battery-notifications?limit=100&offset=0&id=36baa499-ce79-4c03-96e3-93a90fb7f1d9 HTTP/1.1" 200 309 "-" "-"

My provider states endpoint is set to return after a 20 second delay to give my app time to be ready but it seems that the verifier is using the result from the first request before the app was ready, and the test is failing because there is no data available yet. test output for the above log:

Verifying a pact between fleet and battery-api
  Given Fleet has a list of notifications
    a request for notifications
      with GET /battery-notifications?limit=100&offset=0&id=36baa499-ce79-4c03-96e3-93a90fb7f1d9
        returns a response which
          has status code 200
          has a matching body
          includes headers
            "Content-Type" which equals "application/json"

1 interaction, 0 failures
WARN: Ignoring unsupported combine AND for path $['vehicle_id'][0]
WARN: Ignoring unsupported combine AND for path $

It shows 1 interaction but two are always happening behind the scenes. I can see all my test data is duplicated twice in the local instance of the app. It shows no failure locally because my app is now full of this data but in CI where it is a fresh instance, it always fails with:

Matching keys and values are not shown
791        {
792       -  "notifications": [
793       -    {
794       -      "id": "e2490de5-5bd3-43d5-b7c4-526e33f71304",
...
806       -    },
807       +  "notifications": [,
808       +

Can anybody advise me please?

How do all! Have you written a post about Pact, created an open source Pact repo or seen any interesting articles lately? If so, let us know 🙂

I am having an issue with publishing verification results because the tag and version don't exist on the broker yet:

<- "PUT /pacticipants/battery-api/versions/8d80c2b631939740976bcbf27f05049b86a16dcc/tags/ HTTP/1.1\r\nAccept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3\r\nAccept: application/hal+json\r\nUser-Agent: Ruby\r\nContent-Type: application/json\r\nHost: <http://pact.dev.ieu.intelematics.club|pact.dev.ieu.intelematics.club>\r\nContent-Length: 0\r\n\r\n"
<- ""
-> "HTTP/1.1 404 Not Found\r\n"

Can't it create these dynamically?

Couple of shout outs if those with ARM machines fancy lending a hand testing 👍 https://pact-foundation.slack.com/archives/C9VHVEDE1/p1681852451573069 https://pact-foundation.slack.com/archives/C9VPNUJR2/p1681852532785979

👋 Hi everyone!

My team in the organization works in erlang and we have taken an initiative towards using Pact as a contract testing tool for http communication as well as message based communication between services (which can be erlang based or non erlang based). I along with the help of some other folks in my team has done PoC for this as well, and now we want to create a library ‘Pact-erlang’ so that other erlang folks in the community can use this as well !! And for that I would need help from you guys 😃

Hi - I'm looking for some advice on using pact for contracts between a library and a provider; specifically whether the following approach makes sense. Suppose I've created some library components that contain in-built REST calls to a provider pacticipant. These components would then be used in multiple apps. I want to write consumer pact tests for the library itself and publish the results to the broker, which would then record the contract in the usual way. Then I assume verifying pacts in the provider would work as usual, its just more contracts tagged with a different consumer (the library). Assuming I now have an app X that uses this library L. Normally (the non-library case) when I check whether I can deploy a component X to a given environment E I would use

absolute-version

to get the version V of X and then do something like this:

./pact-broker can-i-deploy --to-environment=E --pacticipant=X --version=V

However, if my consumer contracts that X relies on are inside the library L, I assume the equivalent check would be (assuming L is at versions Lv, and that X doesn't have any consumer contracts of its own):

./pact-broker can-i-deploy --to-environment=E --pacticipant=L --version=Lv

To make this work, my deployment script for X needs to know the "pact identity" of the library L (which is not a big deal), but also needs to know the the "pact version" of L. Typically I have used "git version" for pact versions (i.e. something based on the branch+tag+commits_since_tag) as that unambiguously defines the code state of the pacticipant. In that setup, my deployment script just uses

npx absolute-version

to compute V. In the case of a library being the pacticipant, that technique isn't going to work (since the script in running in a git repo for X, not L). This would mean that L would need a different pact versioning approach that didn't rely on git state (e.g. a maven version or an node package version of the library component itself). Such versions must change if the contracts change in any way; in the git versioning approach above this happens automatically, but in the maven/package versioning approach I must increment the version when I make contract-changing modifications to the library. And then ensure that new version is incorporated into my deploy script for X. Does that sound like the right approach, or are there better ways to approach this? tia