ok just managed to join... 🎉🎉🎉🎉

In our pactflow broker we are having an issue where we cannot scroll through anything - has anyone else experienced this?

Hey all, Would just love to give a MASSIVE shoutout to @David Van Couvering (DVC) - eBay, who submitted an incredible 4 substantial PR's for our docs site bringing our guide to Pact Nirvana up to date. You can view it here We would appreciate any comments, feedback or even better submissions, after all it's your tool, we are just the custodians. Why not head over to our #CAN147DFD channel, where you can find out more about the contributions that made this happen, and some more for review Thank you so much @David Van Couvering (DVC) - eBay thank you pactflow platypus slack 🙏💛

How do everyone, I recently did my first ever podcast with our good friend and community champion @Lewis Prescott , it's just been released and you can check it out here 🎧 He has also been busy putting pen to paper, and has published a new blog post 📝 In other news, we have just published some videos and material on how you can use different testing tools such as Cypress, Postman and more can play nice with Pact. You can check out the details in this thread Enjoy happy deployments on a Friday, because you are all contract testing whizz's and have an awesome weekend!🤘

Has anyone used CircleCI with can-i-deploy for short lived branched? As per: https://docs.pact.io/pact_nirvana/step_6#add-can-i-deploy-to-consumer-pr-pipeline I need to pass in the pact url for the contract that has changed (or I could use the consumerVersionSelector?)

Hello everyone! We currently have the problem that we have different providers test classes (for on one contract) located in different modules and therefore in different jvm's when running the tests. Therefore the provider sdk has no way of knowing when all interactions of the contract were validated and therefore never ends up publishing to the pact broker. Is there any existing solution to go about this?

Hi there, Im just reading up on https://docs.pact.io/pact_nirvana/step_5 and am a little confused, where it says

Configure your consumer build to run the Pact tests and publish its pact to the Broker as part of its main build (consult the documentation for your chosen language). Consumer Pact tests typically run after the unit tests, and before deploying to a test environment.

If I have unit tests and pact tests etc running on every PR build, on different feature or task branches (e.g.

feature/PACT-101-do-something-cool

), should I publish it to pact broker as part of this PR build, using commit sha and branch (e.g. HEAD), or do I only do it on PR approval, at which point the feature branch merges into

develop

branch? (we follow git flow consumer side)

Hi all, its good to be here. I have just signed up for pactflow but i have not got the login credentials. I have received both the domain email and the welcome to pactflow email. But nothing on the credentials. Can i please get some assistance with that? Thanks! Please pm me so i can give you my domain details.

Hi Everyone 👋 I have a question. I added all process (webhooks included). Contract creating, publishing, triggering webhooks and verifying (included provider pipeline and webhooks triggered) are running perfectly. But i couln't pass can-i-deploy stage. What am i missing? I'm using this command for can-i-deploy stage by the way. Can anyone help please?

pact-broker can-i-deploy --pacticipant $APP_NAME --version $CI_COMMIT_SHORT_SHA --branch=$CI_COMMIT_BRANCH --to-environment $ENVIRONMENT --retry-while-unknown=12 --retry-interval=10 --verbose

Hi all, we have a custom test harness that I would like to embed the pact verification in. We have our own custom http client already configured, so I would like to be able to use the verification on a slightly different level. What would be the best way to plug in the verification of pacts with responses? (On the JVM)

Hi guys, we are currently POC'ing PACT for our organization and have a conceptual question. Let's say we have a consumer, Checkout API and a provider, availability API. I as a consumer know, that the availability API is calling another Shipping API synchronously in order to deliver a meaningful response. Now the consumer and provider have aligned verbally that, if the Shipping 3rd party dependency is facing timeout or downtime, we as a consumer still expect a valid response. Now we as a small team that is building the POC ask ourselves, is this a test case we should portray as a PACT or not. E.g. with JVM syntax, I could write:

.given("product with stock availability")
.given("transport API being down")
.uponReceiving("A request on /product-availability endpoint")
.willRespondWith()
            .status(200)
            .body(aValidResponseBodyUsingLikeEverywhere())

One part of our group says this is a valid test case, because we've made our verbal contract "On outage of your Transport API dependency we still expect a valid response from you" explicit now. On the other hand the second part of our POC group says, this is an implementation detail and we should not even know, that the provider is using a "transport api" to do its job. Are there any best practices on such an example?

Hi. Apologies if this should be in

pact-jvm

. I've had a PR accepted and merged into the

master

branch of the

pact-jvm

project. We're currently using the 4.1.x line of Pact libraries and really need the change from the PR. I was wondering how we can get the PR merged into the 4.1.x branch? Will this happen as part of a standard process, if so, then when, or should I raise another PR to merge it into 4.1.x?

What do people think about the idea of applying contract testing to externally standardised APIs such as OIDC? On the one hand, a standard is a standard and so in theory, there is no need for additional use cases to be documented - that’s the purpose of the standard. Additional scrutiny via contract testing could be an additional maintenance burden for little value. On the other, contract tests could still illuminate gaps in implementation and the usual value of contract test (consumer coverage, documentation of usage, prevent breaking changes etc.) (context: we have a customer who is wanting to do it on an implementation of an OIDC system and is wondering about the benefits of such an endeavour)

Hello, do you have resources on Message Queue (RabbitMQ) to share?

Hello together, as we successfully made it to the point to reach "Platinum Pact Nirvana" last week (we have a webhook now that triggers the providers' cicd when the consumer changes a PACT), I am starting to learn a bit more about the "Pending Pacts" feature. In the beginning of reading the docs and watching the AMA video I was a bit confused of the feature. Because the objectives of Platinum and Pending Pacts seem to be mutually contradictory to me then, as Platinum is about "Prevent a consumer to merge his PR if his changed PACT is incompatible with the provider". The purpose of Pending Pacts I understood now is in my words: "Do not break the CICD of the provider, if a consumer changed a PACT that the provider is not supporting (yet)". So I was asking myself, "The problem that Pending Pacts solves shouldn't exist with Platinum? At no point in time there could be a PACT on the main branch the provider does not support, because its the job of the consumer to only merge his potentially uncompatible PACT changes to main as soon as the provider supports it.. So what am I not getting right about this? I am confused." 🙂 The more I read about it the more clearer it gets. Also, because I was seeing this "hint" in the Pending Pacts article:

ideally, this should have been done in a feature branch, but for the sake of this example, we'll assume best practice advice was not followed.

https://docs.pact.io/pact_broker/advanced_topics/pending_pacts

So the way I understand it now must be this: Pending Pacts was made for the rare cases in which consumers accidentally or forcefully merge/push their changed PACT even though the PR pipeline wouldn't let them, isn't it? So either bei Administrator's force-merge of a PR even though the PR's quality gate failed, or by directly pushing to the main branch to hotfix something, etc. If in these cases they would at the same time change a PACT that the provider is not supporting, they would fail the providers cicd. Did I get this right?

Hey. I am thinking maybe no - but can you get stubs out of a bidirectional contract published by the provider as an OpenAPI spec? Or does it have to be a Pact contract that drives stubs?

Was going thru the doc, and was wondering if we can use pact to test pagination?

👋 Morning everyone, This oldie but goodie came back to my attention yesterday and it's made me think, what other programming language oddities are you aware of, that increase that cognitive load and complexity when you are developing. https://www.destroyallsoftware.com/talks/wat

This message was deleted.

Hello all I am struggling to think of an example of an “unhappy path” for an asynchronous interaction. Let me clarify: On a synchronous interaction I would consider an unhappy path to be something like when the consumer sends a request to the provider and gets a 400 response back. The consumer test then asserts that the consumer handled the 400 response correctly (e.g. correct exception is thrown). For an asynchronous interaction I would consider an unhappy path to be something like when the provider sends a message that is syntactically incorrect (e.g. with missing mandatory fields) or with wrong data, causing the consumer to reject it. The problem is I can’t force the provider to send a message that is syntactically wrong (as the server code enforces the syntax), that leaves me with trying to send a message with wrong data. In this case should I build a scenario for each wrong data combination that can be sent (this is functional testing), or should I just pick one or two examples of wrong data and build tests for it?

Hi, I am wrapping my head around the Diamond Pact Nirvana step, in specific i am trying to set the "main" tag after my PR is merged to the main branch. But since a "merge" to the main branch creates a new commit I am having the problem, that I cannot call the broker to tag this version with "main", because the PACT version that got published to the broker is the head commit sha of the feature branch. There is technically with github actions no problem to simply add the tag to the correct version (git sha of the feature branch), but this is a bit dirty I think, as this git commit is not going to be the one that is deployed to prod, but the merge commit does. Has anyone had this problem too?

👋 I signed up for a personal free account in addition to my work account. password reset doesn't work.

Hello folks, I wanted to have provider setup for pact-python? any refrences to that and what default port it uses? wanted to understand and setup that?

Hi! We had a few questions regarding the new bi-directional contract feature of Pactflow (and I suppose Pact in general). 1. To our understanding, Pact is great for direct service to service contract enforcement, but what happens when you add an API gateway into the equation where a service needs to go through the gateway before reaching the microservice? Ideally the gateway would not contain much, if any business logic and mostly functions as a passthrough for api calls in our system. The documentation says it simplifies things, but how is unclear. 2. The documentation here recommends not using Pact for a BFF pattern. However, it's unclear if this documentation is meant to apply just to consumer driven contract testing or if it also applies to the bi-directional contracts as well. Could you clarify that as well? In a nutshell, this is the problem we're trying to understand in the following diagram. If using the bi-directional contract feature, where should Pact live (if at all)? • (2) only? ◦ It's clear the microservice is the provider, but who is the consumer? Technically the client, but with the gateway proxying/transforming data potentially, does the consumer contract live here? • (1) + (2)? ◦ Given the uncertainties of (2) alone, does it make sense the chain the contracts? Probably not, but wanted to validate this. • (3) only? ◦ For contract testing purposes, act as if the gateway doesn't exist and just have the contract between the true consumer/provider? • (4) We have something wrong with our contract testing approach entirely and if so, what should be the approach.

Hello, team. Afternoon. I have a quick question, to trigger Provider Verification as part of consumer pipeline, can we simply use Jenkins build job trigger instead of using Webhooks? Are there any drawbacks in this approach? Please advise. Thanks. Something like this -

stage ('Provider Verification') {
            steps {
                build job: 'providerVerificationPipeline'
            }

We'd love to move away from tags to branches and environments, but can't because we use the JVM libraries and Maven plugin, which don't support them. When can we expect that to get resolved? Feels like we're going further and further afield from the main road

Hi there! My team set up Pact a few months ago but could use some clarity / guidance on our setup (which we have likely not configured quite right). My team's service is a lambda function that is the consumer of an SQS queue that is written to by a Ruby gem, which is called by another microservice. The Ruby gem is not just a passthrough service, as it takes some of the parameters of the provider's request and puts them into the body of the SQS message while it attaches some of the others as messageAttributes to the SQS message. We initially set up message Pact tests between the Ruby gem and our consumer, since it is the gem that creates and sends the payload that we need to confirm matches with our consumer microservice’s message handler code. We realized though that this does nothing to guarantee that the greater flow between our provider microservice and our consumer microservice (the flow which we really do want to safeguard in production using pact) is actually unbroken. Our team owns the consumer microservice and the client gem and we make sure that any changes that go live on the consumer microservice are immediately supported by an update to the Ruby gem to match. However, the provider microservice is in control of upgrading the Ruby gem to newer versions and if it is using an old version of the gem, the message put onto the queue by that old version of the client gem will fail to be processed by the new, live version of the consumer microservice. We are trying to reason about what makes the most sense for us given our architecture here. Is there a very different way we should be setting up our Pact integration to meet our contract testing goal of ensuring that the provider and consumer microservices (via the Ruby gem) are always in sync with each other in production? Thank you so much for your time!

Are there any workshops/training available in the office for PactJs Training or is it available only for partners at the moment.

Hey guys, I'm trying to sign up for the Pact Broker but the button is remaining disabled after filling out all the fields?

Hi Team, afternoon. I am getting an error while publishing a pact - [ERROR] PUT JSON request failed with status HTTP/1.1 429 Too Many Requests Failed. Looking for any inputs to troubleshoot. Thanks.