A post in Feature Requests has been marked as closed.

A post in Feature Requests has been marked as closed.

A post in Feature Requests has been marked as closed.

A post in Feature Requests has been marked as closed.

A new comment has been created in Feature Requests.

A new comment has been created in Feature Requests.

A new comment has been created in Feature Requests.

A post in Feature Requests has been marked as closed.

A post in Feature Requests has been marked as closed.

A post in Feature Requests has been marked as closed.

A post in Feature Requests has been marked as closed.

A post in Feature Requests has been marked as closed.

A post in Feature Requests has been marked as closed.

A post in Feature Requests has been marked as closed.

A post in Feature Requests has been marked as closed.

A post in Feature Requests has been marked as closed.

A post in Feature Requests has been marked as closed.

A new post has been created in Feature Requests.

Reminder - update all the places where pact.canny.io is referenced…

A post in Feature Requests hit 10 votes.

Hi, I was wondering how far long on the roadmap (if at all) .NET XML handling is for Pact? If its quite far along I want to see about publishing a recipe for how to handle .NET XML in the interim.

Allow the consumer to send an OpenAPI schema as a contract & mix and match CDCT with bi-directional • If both the consumer and the provider have submitted OAS schemas as contracts, PactFlow should perform an OAS check using

openapitools/openapi-diff

or similar • If the consumer has submitted a regular contract-by-example contract and the provider has submitted an OAS, PactFlw should check the example contract against the OAS • If the consumer has submitted a regular contract-by-example contract & the provider supports it, the provider can verify the CDCT contract In other words, we want the best of all worlds 🙂

Thanks Eddie. You can already do the second 2 now, in case it’s not clear

@Matt (pactflow.io / pact-js / pact-go) if the consumer has submitted a regular contract-by-example and the provider has submitted an OAS PactFlow will check the example contract against the OAS - this is just bi-directional testing. But in this case, will the provider also have an opportunity to evaluate that contract itself? In other words • If the OAS check fails (in the broker),

can-i-deploy

says "no" • If the CDCT evlauation (on the provider) fails,

can-i-deploy

says "no" Only if both the OAS check (in the broker) and the CDCT evaluation (on the provider) succeed is the contract OK.

Hello. I recently came upon this: https://pactflow.io/blog/extending-pact-with-plugins/. Are there any plans to extend bidirectional provider validation to asyncapi? Thanks.

You mentioned a blog - don't forget to add useful content and articles to this page 👉 https://docs.pact.io/blogs_videos_and_articles

@Spencer has left the channel

A new comment has been created in Feature Requests.

A new comment has been created in Feature Requests.

TL;DR: I’m proposing a way for consumers to verify they exercised all interactions in a shared

pact.json

, even if they didn’t generate it. Pact already supports provider verification from a pact file; this would add optional support for consumer-side verification by failing tests if any interactions weren’t used. It’s a small step toward bi-directional confidence, without compromising the consumer-driven philosophy. Hey all 👋, I have a proposal that I think could complement Pact’s philosophy while supporting teams working in highly collaborative environments. In some cases, teams may want to mutually agree on a shared

pact.json

file, hand-written, but collaboratively authored and version-controlled, and use it as a behavioral contract. This allows both sides to contribute: the consumer knows what it wants, but the provider knows what it can do. It would be really helpful if Pact supported workflows for teams that want to validate both sides of such a contract, even when the consumer isn’t generating the pact file through tests. Right now, Pact already fully supports the provider side of this setup, but not the consumer side. In this verification approach, the consumer would: • Spin up a stub/mock server from the shared pact (as Pact already allows) • Run consumer tests against that stub (doesn’t require Pact support) • Fail the test suite if any interactions in the pact were not exercised (not currently supported, but would be really helpful) The goal is to ensure the consumer really uses what the pact says it does, just like it does with the provider. I know Pact is consumer-driven and discourages hand-written contracts, mainly because people might rely on the contract instead of verifying their usage through real tests, and I fully agree with that philosophy. This proposal isn’t about skipping tests, it's about adding strictness to ensure the consumer truly adheres to the shared contract. It's a small step toward bi-directional testing without compromising the core consumer-driven model. I’m asking because Pact provides the strongest confidence in contract testing available today — thanks to its precise request/response mapping (not just schema validation) and the compatibility matrix enabled by

can-i-deploy

. Creating a new tool just to support this small bi-directional need feels like a waste when Pact is already so close to solving it. Would this be a welcome addition to the tooling, for example, a flag in the mock server or test library that serves only one interaction at a time, to force full coverage? Or is this too far outside Pact’s intended model? Also, let me know if this is the right place to ask for that