hello i see

interactionId

in HAL browser, not user-friendly names. is it something new-ish ?

"testResults": [{
      "interactionId": "0eac6b0ba31719c60b6d5d0c1a5a1ceab75943c2",
      "mismatches": [{
          "attribute": "body",
          "description": "Actual map is missing the following keys: reason",
          "identifier": "$"
        }],
      "success": false
    },... {
      "interactionId": "30ac1652bdc5ce4d8109d0ccabb4b99f6adc0013",
      "success": true
    }]

What is the recommended approach to force a deployment of a specific version (regardless of consumer or provider verification status) when

can-i-deploy

fails? I'm exploring the following workaround — is this a valid approach? 1.

create-version

2.

publish-pact

/

verify-pact

3.

can-i-deploy

(fails) 4. force deploy anyway (with override flag or manual trigger) 5.

record-deployment

Are there any risks or better alternatives to this flow?

Attempting to use Pact with rust & gRPC. Having trouble when it comes to multiple synchronous messages to the same endpoint but with different request data. The mock server receives a request and responds with the response for a different request message. Example implementation here: https://github.com/MeatballSub/pact-help

Hey, A quick question. Does Pact support GitLab CICD integration? I could find anything related to GitLab CI integration in the documentation as it's all about GitHub.

For those of you looking for a practical, hands-on course on contract testing with Pact, my self-paced, online video course is now complete and available at https://ontestautomation.teachable.com/p/practical-contract-testing-with-pact Course features: _ Dozens of short, to the point instructions videos, with subtitles and transcripts _ Quizzes to test your theoretical knowledge about contract testing _ Hands-on programming exercises to put that knowledge to the test and write and run your own contract tests and make them part of a build pipeline The exercises are available in Java for now. I'll start adding exercises in other languages very soon, starting with C#, then JavaScript / TypeScript. To celebrate the (long overdue) go-live of this course, you can use the coupon code 50PERCENTOFF at checkout for, you guessed it, 50% off the regular price of USD 149. This coupon code is valid until Sunday, July 13, 11:59 PM CEST. (Posted with permission from the Pact team)

Hello. I have a question regarding running provider verification of recently published pacts for different deployments. How can you run provider verification of PACT changes against versions of the provider that have been deployed to other environments? At the moment, we are just running provider verification via a webhook against what's on the latest version of the main branch.

Hi all - we have some unit tests using Pact via FFI for contract verification and I'm trying to improve their performance. The Application is in C++ and we run the tests via GTest. We use an updated fork of Pact's C++ client which uses FFI under the hood. Each test does the following - 1. Creates a provider instance 2. Instantiates a custom plugin 3. Performs verification Rust is not my area of expertise, so apologies if this isn't correct but it looks to me like each call to pactffi_using_plugin will block the client thread for at least 0.5s, so each of our unit tests is taking at least that long to complete.

let result = RUNTIME.block_on(async {
          let result = load_plugin(&dependency).await;

          // Add a small delay to let asynchronous tasks to complete
          sleep(Duration::from_millis(500)).await;

          result
        });

I've tried using a fixture to make the plugin and provider instance persistent across multiple tests, but haven't had much luck (it looks like there's some state not being cleaned up between unit test runs - or maybe ths issue is with our plugin?) - the first test passes but subsequent ones fail due to contract verification failures. I can probably provide a minimal example but I thought I'd ask first in case you had any ideas. Many thanks!

Hi In my org we had done an alignment to adopt pact as a contract testing framework, which will help us write the pact tests which then eventually help us eliminate any contract breakage between services in production or release branches. Now I have multiple questions regarding consumer and provider side of things: Consumer: 1. In the consumer application, should i publish pacts for each version (version being a commit id when the squashed commit merges in any branch) and branch (develop, release branch 1, release branch 2) OR should I only publish when the pact changes with the version and branch name? 2. When writing pacts in the consume side, what naming convention should we follow for consumer and provider. If I choose to use consumer name as the actual service name, it will be too generic and all set of interactions for that consumer service and the provider service will all go into that pacticipant. Also will I get this visibility of which interaction’s verification has failed in the pact broker OSS version ? Provider: 1. Should a provider write pact test without the consumer actually implementing their pact tests ? If yes, then lets say the provider writes the pact test for their service and in future the consumer also writes the pact test, uploads the pact to pact broker and for some reason the provider pact tests (verification starts failing) starts failing in this case. Should we stop the provider PRs in this case ? 2. In our current provider verification, we have passed consumer version selectors as “matchingBranch:true” since all our services in the org follow the same branch name convention and the release branches are cut at the same time, which then means that the provider will only pull in the pact for that particular branch? Is this the latest pact from that branch (latest version of consumer indirectly) ?

Hello. Quick question. For events, is there any guaranteed order of the events that get emitted?

Hi, I'm utilizing the capability of pact SDK to build a contract broker in my company for internal rpc services. The broker I'm building aims to support contract publishing, contract retrieval and response verification. A quick question: our company uses a set of self-defined rpc protocols, what's the best practice of applying pact to our company's rpc protocols? Does pact directly support that? Or should I use an adapter layer to first transform the rpc response to the model that rpc can identify, and then use methods like compareSynchronousMessage() to process verification?

Hi, is it possible for multiple consumers to share a common contract with the same provider? I mean if they call the same API with the same expectation.

Hi, I'm thinking about such a scenario for RPC consumer and provider: if consumer has pulished contract to the broker, and later in the integration test stage the consumer need to mock the dependency of the provider, can we directly generate mocked response based on the interaction rule in the contract so that the consumer don't need to write mock tests? I think it would be a benefit for the consumer, and a good point to persuade them to adopt contract testing. Has anyone tried this approach?

Is there any code demo of consumer test for non-http synchronous messages case? Prefer Java. Thank you!

Looking for a bit of advice on how to handle stringified json inside of a message body and regex against a couple of the keys. What I was trying to do is something like this

it(`consumes a valid ${type} message`, async () => messagePact
         .expectsToReceive(`a valid ${provider} ${type} message`)
         .withContent({ Body: regex('tenantId', 'tenantId') })
         .withContent({ Body: regex('userId', 'userId') })
         .withContent({ Body: regex('verb', 'verb') })
         .withContent({ Body: regex('actor', 'actor') })

But the contract will expect the Body to be

Body: 'actor'

{
      "contents": {
        "Body": "actor"
      },
      "description": "a valid assessment-artefact-service xapi message",
      "matchingRules": {
        "body": {
          "$.Body": {
            "combine": "AND",
            "matchers": [
              {
                "match": "regex",
                "regex": "tenantId"
              },
              {
                "match": "regex",
                "regex": "userId"
              }
...

If I manually delete the contents from the contracts, then the pact is valid and passes. I've got about 300 queues running like this and refactoring an entire architecture isn't feasible.

Hey, following this documentation https://docs.pact.io/pact_broker/webhooks#example-cicd-and-webhook-configuration there seems to be an approach to providing a webhook that lets the CI know when to make a call to

can-i-deploy;

however, this approach only works when the

contract_requiring_verification_published

event is triggered. it there a way to call a webhook that lets CI call

can-i-deploy

when there is no change to a contract?

blobwave Happy Friday everyone! Do you have trouble with your sec-ops teams giving you grief about ruby processes on your machine, when all you want to do is publish a pact to a broker? 👮 Do you wonder why a wee cli, weighs in at circa 40mb? Because distributing ruby is sadblob I am after willing volunteers to give the rust rust rewrite of the pact_broker-client a whirl. https://github.com/YOU54F/pact-broker-cli Drop us a shout in the 🧵 if you are keen 👇

👀 https://pact-foundation.slack.com/archives/C9VECUP6E/p1754972602066339 🚀 I know this has been a long time coming, but the effort, diligence and attention to detail in the latest release of Pact Python is chefkiss . Amazing work @Joshua Ellis , I’m sure the Python community will love this 👏

Happy Friday everyone blobwave

Hi guys I have a question: some engineers in my company feel writing Pact DSL not convenient and don't want to do it. I've tried to provide a prompt template to generate Pact DSL by LLM automatically, but hard to achieve compile error free. Anyone has thoughts on it? Really appreciate for any advice.

Hi PactFlow team — I have a meeting with @Rohit Thadhani in ~30 mins but haven’t heard from him or received a calendar invite. Could someone help check with him if we’re still on? My team and management are waiting on confirmation. Thanks!

This is a general question about matching, but applies to Pact-JVM. How do I specify/match an empty JSON array. We have a response that looks like:

{
  "destinations": [],
  "cities": [],
  "airports": [
    {
      "code": "MSY",
      "name": "Louis Armstrong New Orleans International Airport"
    }
  ]
}

I want to match that "destinations" and "cities" are indeed empty lists. I am trying to use

maxArrayLike("destinations", 0, example)

but I get an error on the Consumer test complaining that I either cannot leave that field empty, or that the example of 1 doesn't match the expected size of 0.

Hey everyone! 👋 I'm hoping to get some community feedback on my company's approach to contract testing, as it feels quite different from my previous experience. I want to make sure we're on the right track. Here's a quick rundown of our current setup: • Consumer Side: When consumers generate contracts, there isn't a verification step against a mock service. The consumer code doesn't seem to be asserting its expectations before the pact file is created. • Provider Side: For verification, we send the requests from the pact file directly to a live, deployed environment called "temp". This is a task-based environment that contains recent feature changes. We are not using mock servers or any test doubles; it's a real, running env with services. • Centralized Repo: All contract tests for all our services are being written in a single, centralized repository. My main concern is the dependency on a live environment for provider verification. This feels less like a contract test and more like a targeted integration test. The core benefit of testing components in isolation seems to be lost. So, my question for you all is: Is this a valid implementation of contract testing? I'm worried that by relying on a live environment, we're missing out on the speed, reliability, and independent deployability that contract testing promises. It feels like we're just asserting a response from a live server, which doesn't seem to be the point. Any thoughts, advice, or validation on this would be hugely appreciated! Thanks in advance.

Hi guys, I am promoting contract testing in my company, and need more strong evidence to persuade other engineers to adopt it. Can someone share some context and scenarios about why you used contract testing, and what pain point it resolved in your company? Really appreciate. 🙏

blobwave Hey all, I am sure some of you have been exploring AI, maybe you’ve been exploring it with Pact? I’d love to hear how your experiences have been, good, bad or indifferent. If you have any ideas for areas where AI could be leveraged to improve your Pact experience, be sure to let us know. 🤖 💛

Hi all, would love to know if there's anywhere I can keep tabs on to keep up to date with progress of the V2 plugin interface? I suspect not much is happening towards it right now as it's very difficult to track anything recent down 😄

Hello, We are implementing bi-directional testing in some of our projects, but it's not clear to us how the contract matching is done between consumer versions, provider versions, and different environments. For example, is the environment matching one-to-one (i.e., consumer 'dev' with provider 'dev'), or are they separate? Can a consumer in a 'dev' environment match with a provider in 'production', for instance? And how do we control that? Thank you.

Hey there everyone! I have a question on the flow of working with pending pacts. We just ran into a problem, where the pact was verified on a feature branch and the results were published to the broker as part of the pipeline. This causes the provider tests on most other feature branches to fail. The documentation (and from I can tell the code as well), a pact is verified if either a) The contract has been verified on this branch before. b) The contract has been verified on any branch, that existed before this branch. Does this mean, the other feature branches would need to wait for the branch that originally verified the contract to be merged? Or shouldn't a feature branch upload verification results in the first place? For context: • the consumer team hasn't fully finished up setting their pact configuration and so far has only published pacts for their tagged versions (where the providerBranch is also set to the Tag). Their main branch in the Pact Broker is not yet set. • we are using WIP pacts What are we doing wrong?

Hey everyone, Does anyone have any experience guidelines or tips for measuring the coverage of our pact tests? As part of our transition to pact we have added tests for most of our consumers, and we believe we are pretty far. However we are looking for a way to measure the coverage from the consumer perspective. Since we'd like to know how many integrations are still missing tests. How do other deal with this?

Hi all (sorry for a long message) We’re using Pact.Net with the following setup: 1. One system consisting of: ◦ Client-side UI ◦ Web API BFF ◦ The BFF has a couple of GraphQL dependencies downstream (these are our Pact providers). 2. We run UI tests against the BFF and use Pact to mock the downstream GraphQL providers (Pact.Net consumer tests generate the contracts). 3. We then run provider verification against these contracts for the GraphQL services. Our challenge is around _IDs_: • The UI tests use static IDs in GraphQL queries (e.g.

room(id: "123")

), and these IDs are recorded in the pact. • When we run provider verification, those IDs usually don’t exist in the provider’s real database. • We have a provider state setup tool that runs mutations to create test data, but the provider uses identity/auto-generated IDs, so the IDs returned from setup don’t match the hardcoded IDs in the contract. Conceptually, we’d like to: 1. In provider state: run a mutation to create test data and let the provider assign an ID. 2. In verification: use the ID returned from setup in the GraphQL request for that interaction. Questions: 1. Is there any supported way in Pact for provider state output (e.g. a newly created ID) to influence or substitute into the request during provider verification? 2. If not, what’s the recommended way to handle this pattern of: ◦ Consumer/UI tests that send static/example IDs ◦ Providers that rely on auto-generated identity columns?