An aside, anyone know what the deal is with the

jest-pact

library? At first glance, it looks like its getting frequent updates, but as far as I can tell it doesn't work with

PactV4

. I'm assuming then that I should be avoiding it? > https://github.com/pact-foundation/jest-pact

Values from Provider State Good morning! I would likt to include provider state values in my TypeScript consumer's JSON body while preserving their original types (numbers, booleans, array, etc.). Pact-jvm's

valueFromProviderState()

works perfectly for this, but pact-js only has

fromProviderState()

which appears to be converting everything to strings, making the provider test fail. Is there a way to access provider state values in pact-js without string coercion, or is this feature planned? Thank you in advance!

This message was deleted.

Hi, How to tackle testing enum in bi-directional approach ??? I have a consumer test like below which want to check one field of enum type. Consumer wiill have NEW OPEN values Imagine that provider contract (OAS spec file) contain enum which has one more additional value ie: NEW OPEN CLOSE. Once i trigger and publish this consumer test pact file to pactflow and run can i deploy against provider it saying that its compatible, which is kind of true as new value in provider should not break anything, however in a past there was situation that consumer was not able to deserialize that response due to new value. How to tackle this isue and break contract at can i deploy stage (i.e compare that with provider enum properly)

Hi everyone! I have a antoher question 🙂 Is it possible to introduce contract testing for a third-party API when the provider doesn't offer an OpenAPI (OAS) schema that could serve as the contract ? In my case, the third-party API exposes a GraphQL schema: https://prismatic.io/docs/api/#prismatics-graphql-schema Are there any recommended techniques or patterns for applying contract testing in such scenarios—especially when using paid version of Pactflow? Would love to hear how others have approached similar challenges!

@Kieran McCarthy has left the channel

Hi. I looked documentation but didn't find answer for my question. What the behaviour should be for

like

matcher in case when it faced array inside object? Ex,:

like({
  field1: "one",
  field2: 2,
  field3: [1, 2, 3],
})

or

like({
  field1: "one",
  field2: 2,
  field3: [{f1: "ff", f2: 2}, {f1: "aa", f2: 5},{ f1: "dd", f2: 1},],
})

In https://docs.pact.io/implementation_guides/javascript/docs/matching I see next for

like

matcher

Note that you can wrap a

like

around a single value or an object. When wrapped around an object, all values and child object values will be matched according to types, unless overridden by something more specific like a

term

.

and for V3 matcher

Applies the

type

matcher to value, which requires values to have the same type as the template

Or I must explicitly declare

eachLike

for arrays in

like

section?

Hello everyone! Does anyone have experience setting up a contract verification webhook in AWS? Our provider is a set of API endpoints which we deploy to AWS via cloudformation. We tried setting up an API endpoint (using AWS API Gateway) with a Lambda integration, but the pact-js verifier did not like running inside a Lambda. In the tracing logs, The Pact verifier connects to the broker and starts verification, but the Lambda function terminates with a Runtime.ExitError after ~1 second. The process appears to be cut off while fetching pacts from the broker. We are providing these npm packages to the lambda

"@pact-foundation/pact-core": "^17.0.1",

"@pact-foundation/pact-core-linux-x64-glibc": "^17.0.1",

Hello all, I'm trying to use Verifier for provider. I configured it with

describe('Pact Verification', () => {
    it('validates the expectations of Consumer', async () => {
        const opts = {
            provider: '{my}-example-provider',
            providerBaseUrl: '<http://localhost:3000>', // your service endpoint
            pactBrokerUrl: 'https://{my-url}.<http://pactflow.io/|pactflow.io/>',
            pactBrokerToken: '{my-token}',
            consumerVersionTags: ['main'],

        };

        await new Verifier(opts).verifyProvider();
    });
});

when running such a test I'm getting

2025-11-26T13:51:47.013550Z  INFO ThreadId(11) pact_verifier::pact_broker: Fetching path '' from pact broker
2025-11-26T13:51:47.809031Z ERROR ThreadId(11) pact_verifier: No pacts found for provider '{my}-example-provider' matching the given consumer version selectors in pact broker 'https://{my-url}.<http://pactflow.io/|pactflow.io/>': Link/Resource was not found - No pacts for provider '{my}-example-provider' were found in the pact broker. URL: 'https://{my-url}.<http://pactflow.io/|pactflow.io/>'
2025-11-26T13:51:47.810401Z ERROR ThreadId(11) pact_verifier: Failed to load pact - No pacts found for provider '{my}-example-provider' matching the given consumer version selectors in pact broker 'https://{my-url}.<http://pactflow.io/|pactflow.io/>'
2025-11-26T13:51:47.811140Z  WARN ThreadId(11) pact_matching::metrics:

There are pacts published by consumer for given provider in my instance and I also double checked that tag name is proper. I'm not sure about that 'Fetching path '' ...' which is empty, but I'm not sure what's the path and how to set it What should I also check? Is there any option to improve verbosity or recommended debugging path?

Hi - I'm struggling to understand how to use the

eachKeyMatches

matcher properly; the documentation here is terse, and I haven't been able to find any working examples out there that really do a good job of explaining it. Any pointers much appreciated TIA.

Has anyone seen this before? Pact hangs when I make the body of my contract be

{}

. But if I remove the body or make it something else (e.g.

{"foo":"bar"}

) then it does not hang 🧵 ✍️ EDIT: Yep it's #1602 again. Fix for me was to add:

requestFilter: (req, _, next) => {
  delete req.headers['content-length'];
  next();
},

Hello all, we have been trying to build provider tests with the pact-js library but have a problem so thought to reach out. It appears the

Verifier

is unable to verify both synchronous and asynchronous contracts for a singular Provider. We can build a test solely for synchronous contracts using

Verifier

and solely for asynchronous contract using MessageProviderPact but using

Verifier.messageProviders

opt breaks those same verifications. We have created a example project to demonstrate. Does anyone have any experience of running asynchronous and synchronous side by side for one Provider? Any guidance would be appreciated In other languages it appears that people get around this by using filters such as Java however pact-js doesn't have this. Filtering upon interaction type would solve our problem and allow us to verify both asynchronous and synchronous contracts for one Provider under two test files. To explore a possible solution, I made changes to the pact-js library to introduce comparable filter functionality in this draft fork. This was supported by AI and I have not contributed to pact-js before so I would be open to discussion if this is the correct approach Thanks, Eoin : )

Hello everyone, 👋, I’ve been asked to create a working POC for contract testing using Pact in my organization, and I’d really appreciate guidance from the community on best practices for our scenario. Current System Landscape • 7 Micro Frontends (independent repos & deployments) • 10 Microservice Providers (independent repos & deployments) • Almost every frontend consumes most of the backend services • Teams are fully decoupled (separate CI/CD pipelines) Current Pact Setup (POC) • A separate QA-owned repository for contract testing • Consumer tests: -Pact consumer tests written in the QA repo -Requests are constructed manually (HTTP calls) -Verified only against the Pact mock server -No real frontend component or business logic involved • Provider tests: • Provider verification tests also live in the QA repo • Verified using: -In-memory DB -Fake/local server • Not verified against the actual deployed provider base URL This setup is technically working, but: • Contracts are not validated against real consumer logic • Providers are not verified using real provider runtime behavior • QA owns everything, but confidence feels limited • Core Concern > The contracts are being validated in isolation, not against the actual consumer and provider implementations. My Questions- 1. Is it possible (or recommended) to verify Pact contracts against real consumer and provider logic while keeping ownership with the QA team? 2. Are there any established patterns where: • Consumers remain untouched • Providers remain untouched • QA still owns contract definition and verification 3. Would approaches like: • Running provider verification against a real provider instance in a special “contract-test” mode • Using ephemeral environments / in-memory databases • Executing consumer tests through real frontend service layers be considered valid and scalable? 4. From a Pact philosophy perspective: • Is a QA-owned contract testing model like this anti-pattern, or • Is it acceptable as long as contracts are published and verified correctly? 5. In real-world micro-frontend + microservice ecosystems: • Who usually owns Pact tests? • How is trust maintained between teams?

hi @Matt (pactflow.io / pact-js / pact-go) thanks for your valuable inputs🙂. but I have a question, if consumer and provider code base are different, then how we can get consumers tests inside the consumer repo as it is expected to be in consumer repo

I noticed that the

@pact-foundation/pact-cli

package is triggering CVEs about

minimatch

. Is there a way that I can assist with some dependency updates, so I don't have to add an

overrides

block to the packages that are referencing it?

Hello, is there any documentation or example around using pact for testing Microfrontends or if you could please suggest an approach to go about this.. I am using ModuleFederation runtime to load the MFE. 1. First, I fetch the Remote component 2. Then, I pass the props that are available with the host app to that component 3. No, there is no bi-directional communication - just first load The structure • Consumer - Shell app • Producer - MFE app (There could be multiple of them)

@Paul Williams has left the channel

We are using C# for backend development. Does Pact support C# for contract testing on both the consumer and provider sides? If yes, what libraries or frameworks are recommended, and are there any limitations compared to the Node.js implementation?

Hello, Can someone point me to how to set the "pending" flag per interaction in Pact TS consumer tests? In the Python implementation, this is done by calling .set_pending(pending=True).

hmmm not great. i think i just ended up making the matcher very generic

@Norbert Gulácsi has left the channel

Hello all! 👋 We currently define our API response models using Zod schemas, and we’re duplicating the same structure again in Pact matchers. For example, instead of defining a response in Pact like: account: { email: MatchersV3.string('user@automated.testing')} we already have an Account object defined in a Zod schema that describes the same fields, types, and nullability. Is there a recommended way to reuse or derive Pact contracts (or matchers) from existing Zod schemas, so we don’t have to redefine the same response objects in Pact and risk schema drift? Or is the expected approach to define the response shape explicitly in Pact and treat the contract as the single source of truth? Many thanks! :)

Hey folks, We just open-sourced a library we've been using internally at SEON for Pact.js contract testing, thought it might be useful for others here. Pact is powerful but the setup boilerplate adds up fast. Every team ends up writing the same plumbing. The library extracts those patterns into composable utilities. What's in it: - createProviderState / toJsonMap : typed provider state params without the JsonMap conversion headache - buildVerifierOptions / buildMessageVerifierOptions : one call to build complete VerifierOptions for HTTP and message verification - createRequestFilter : injects auth headers into verification requests without the Express type gymnastics - handlePactBrokerUrlAndSelectors : reads env vars and assembles the right consumer version selector strategy automatically github: https://github.com/seontechnologies/pactjs-utils npm: https://www.npmjs.com/package/@seontechnologies/pactjs-utils docs: https://seontechnologies.github.io/pactjs-utils/ The repo also functions as an educational resource, dogfooding the lib, and showcasing vanilla vs lib versions of the same tests. P.S. For those moving toward agentic QA: BMad Test Architect now has a pactjs-utils installation option. It’s designed to create and self-heal contract tests using these patterns out of the box. https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/

Walkthrough of the BMAD Test Architect module in action, setting up PactJS + pactjs-utils infrastructure from the ground up. Watch as the test architect agent autonomously configures the CI, writes & executes the tests from scratch. PR: https://github.com/muratkeremozcan/couture-cast/pull/72 vid: @Matt (pactflow.io / pact-js / pact-go) @Yousaf Nabi (pactflow.io) @vijay singh

Quick question / note. I have implemented a state handler for a parameterized provider state like this:

'an address with ID {addressId} does not exist': async (params?: { [name: string]: string }) => {
  const addressId = params?.['addressId'];

  if (!addressId) throw new Error('addressId param is required');

  removeAddress(addressId);
},

This works, and I see that the

params

object contains the proper values. However, VS Code tells me:

Type '(params?: { [name: string]: string; }) => Promise<void>' is not assignable to type 'StateHandler & ((state: string, params?: { [name: string]: string; } | undefined) => Promise<unknown>)'.
  Type '(params?: { [name: string]: string; }) => Promise<void>' is not assignable to type 'StateFuncWithSetup & ((state: string, params?: { [name: string]: string; } | undefined) => Promise<unknown>)'.
    Type '(params?: { [name: string]: string; }) => Promise<void>' is not assignable to type '(state: string, params?: { [name: string]: string; } | undefined) => Promise<unknown>'.
      Types of parameters 'params' and 'state' are incompatible.
        Type 'string' is not assignable to type '{ [name: string]: string; }'.

If I update the handler signature to

'an address with ID {addressId} does not exist': async (state: string, params?: { [name: string]: string }) => {

state

obviously now contains the provider state parameters, and

params

is

undefined

. I'm not a TS expert but doesn't that mean there's something wrong with the type definitions? Or am I missing an explicit type definition package in my project maybe? All I'm using is

"@pact-foundation/pact": "^16.5.0"

.

hi! Anyone else hit this with pact-js 16.5.0? It pulls in https-proxy-agent@9, which is ESM-only, and our Jest (ts-jest) suite blows up at import:

SyntaxError: Cannot use import statement outside a module
  (https-proxy-agent@9.1.0/dist/index.js)

The bump PR (#1731) actually called this out and showed it breaking the example jobs, but it got merged and there's no follow-up. We pinned it back with an override (

@pact-foundation/pact>https-proxy-agent: 7.0.6

) and we're green again. Is a revert or lazy-import fix on the radar?

LARION's Technology & Innovation team built a visual explorer of the BMAD framework for their own engineers, and gave pactjs-utils a full section: Zod to Pact matchers, provider states, verifier config, request filter auth injection, MCP server. Nobody asked them to. larion-tech-innovation.github.io/BMAD-Explorer/BMAD/bmad-tea-knowledge.html#… @Matt (pactflow.io / pact-js / pact-go) @Yousaf Nabi (pactflow.io) @vijay singh

Amazing - your evangelism is chefkiss Murat!

(and the package is also fantastic)

The BMad Test Architect, which is Pact fluent and opinionated (among other kinds of testing), can now run its test-review skill in CLI Which means, it can be used for code reviews. I created a github action to make usage easier github.com/muratkeremozcan/tea-test-review Add one YAML file to get a score, criteria table, deduction ledger, and merge recommendation. The CI exit code carries the verdict, so teams can use it as a required check. Claude and Codex are supported. @Matt (pactflow.io / pact-js / pact-go) @Yousaf Nabi (pactflow.io) @vijay singh