https://pact.io logo
Join Slack
Powered by
# general
  • v
    Provider verification test passes and deployed till uat but can-i-deploy of consumer is failing. I am not able to understand why it is failing
    y
    • 2
    • 1
  • l
    Thank you to @Yousaf Nabi (pactflow.io), @Tien Vo and the PACT team for sending me a Tee for the participation with Tien on PHP I was helping because I like to explore cool tech and it seemed there was a gap in PACT PHP, which in 2022 I was using for work. It's amazing to see all the improvements made and the group going from success to success!
    m
    g
    y
    • 4
    • 5
  • a
    Hi I am getting this in pact broker and can i deploy for this version is failing what is the reason here i m not able to get it. Here i see it is saying pact was pre verified but status colour is green that is making it more confusing
    y
    • 2
    • 1
  • d
    👋 I'm trying to enable 
    can-i-deploy
    to environment 
    staging
    from the provider, so far i have done the following • Publish consumer contracts • Added provider verification for the above consumer • Added the webhook verification when consumer changed something Here is the error from provider
    Copy code
    pact-broker can-i-deploy \                                               
  --pacticipant=participant-video-service \
  --version=33719d37665b7f096c6e88036cd5194faab6e4f8 \
  --to-environment=staging \
  --broker-base-url="<https://usertesting.pactflow.io>" \
  --broker-token="<>" \
  --output=json
{
  "summary": {
    "deployable": null,
    "reason": "There is no verified pact between version 33719d37665b7f096c6e88036cd5194faab6e4f8 of participant-video-service and the version of analytics-video-data-service currently in staging (4474f9fd7db43b47b1d9bb390e32a4f29faf7b55)\nThere is no verified pact between version 33719d37665b7f096c6e88036cd5194faab6e4f8 of participant-video-service and a version of data-platform currently in staging (no version is currently recorded as deployed/released in this environment)\nThere is no verified pact between version 33719d37665b7f096c6e88036cd5194faab6e4f8 of participant-video-service and a version of participant-test-plan-service currently in staging (no version is currently recorded as deployed/released in this environment)\nThere is no verified pact between version 33719d37665b7f096c6e88036cd5194faab6e4f8 of participant-video-service and a version of participant-video-manager-MESSAGE currently in staging (no version is currently recorded as deployed/released in this environment)\nThere is no verified pact between version 33719d37665b7f096c6e88036cd5194faab6e4f8 of participant-video-service and a version of participant-video-manager-REST currently in staging (no version is currently recorded as deployed/released in this environment)",
    "success": 1,
    "failed": 0,
    "unknown": 5
  },
  "notices": [
    {
      "type": "error",
      "text": "There is no verified pact between version 33719d37665b7f096c6e88036cd5194faab6e4f8 of participant-video-service and the version of analytics-video-data-service currently in staging (4474f9fd7db43b47b1d9bb390e32a4f29faf7b55)"
    },
    y
    m
    • 3
    • 53
  • k
    Heya, I hope I have the right channel for this. I am trying to introduce (consumer driven) contract testing in our company, and picked a frontend and backend service as a pilot, but I seem to run into a chicken-egg problem, because they are already sharing an openapi spec file between them. And the frontend uses this file to generate the backend calling code. For the sake of example and to test my knowledge, lets forget the existance of the openapi file for a sec, and look at a scenario where the frontend is building a new feature that requires a new endpoint of the backend. If I understand the concept of consumer driven correctly, then it should look something like: 1: Frontend creates a new feature, and add some point during development reaches the point where they require the new backend call to get some data. 2: Frontend creates a new consumer test, in which they stub the backend in a way that they would like to receive the data. 3: When the test passes, a new contract is created containing the new endpoint, and data they expect to receive (the interaction) 4: Frontend pushes the contract to the broker 5: Backend pulls the contract from the broker, provider test fails, and implements the endpoint according to the expected result. 6: Once the provider test passes, both consumer and provider proceed to merging and deploying their changes. First of all, is my understanding so far correct? Now back to the usage of an openapi spec. Where I struggle in this specific case, is that the consumer uses the openapi spec to generate their backend calling code. If it is up to the consumer to write a consumer test first, how can they do that when they depend on the spec file to generate the calling code? The frontend cant write a test without the openapi file, but the backend cant provide the new openapi file without a new contract first. How do you transition from a 'provider first' to a 'consumer first' way of working when they were already sharing openapi file? The only thing I can think of is that the frontend first manually writes some temporary backend calling code, and uses that in the test. New contract is generated and pushed, backend pulls, implements, and sends the new openapi spec back to the frontend, where they then generate the new backend code, and replaces the temporary code with the generated one. But that seems very cumbersome and a very tough sell. When theyre already using openapi, perhaps the most logical answer would be to use bidirectional testing? But we are specifically looking into consumer driven, because we want to do value specific asserts. And bidirectional only does structural asserts right?
    y
    • 2
    • 4
  • j
    probably a silly question but my team is really struggle with which jobs we need to be running in which context for a provider. 1. we have a webhook trigger job to verify our consumers. this seems to make sense 2. we should have can-i-deploy running in our main pipeline before deployment to make sure that we have an acceptable pact agreement. makes sense 3. branch pipelines with changes going into the main branch (MR/PR) this is where we are stuck a. we had roughly the same trigger pipeline running verifyPacts but this was aparently cause consumers to verify against the wrong version and fail (the branch instead of mainline) b. it seems like we should be able to run can-i-merge but this would require publishing the verification which was causing us issues. would be great to get some clarity on this so we can figure out what exactly it is that we need to fix. i feel i have scoured the documentation quite a bit and everything seems to be in the context of the consumer thinking2
  • f
    I’m a bit confused about the way consumer tests work when it comes to multiple interactions. For context, I’m working on a C++ wrapper that uses a pact plugin for a custom transport, in case that matters. When I create a pact and define the interactions in each test case, each time my 
    runTest
    method is called which calls 
    pactffi_create_mock_server_for_transport
    I see the 
    StartMockServer
    method being called on the plugin with the JSON pact only containing the interactions defined up to that point. Now the part I don’t understand is what the mock server is supposed to do here, is it supposed to listen for all of the defined requests? If so, how are you supposed to distinguish between interactions with the same request but with different provider states? Or is the idea that the mock server only responds to the last defined interaction?
    r
    • 2
    • 27
  • f
    We’re working on using matchers using the 
    pactffi_matches_json_value
    function, and are seeing some unexpected behavior for some more advanced rules where the check passes even though it shouldn’t… For example, with an 
    arrayContains
    matching rule, no error is returned even though an array with one element that doesn’t satisfy the matching rules is passed to it. Here’s the line in the pactffi log for the check:
    Copy code
    2025-03-31T15:16:12.632536Z DEBUG ThreadId(01) pact_matching::json: JSON -> JSON: Comparing '[{"baz":42,"foo":"bar"}]' to '["bla"]' using ArrayContains([(0, MatchingRuleCategory { name: BODY, rules: {DocPath { path_tokens: [Root, Field("baz")], expr: "$.baz" }: RuleList { rules: [Type], rule_logic: And, cascaded: false }} }, {})]) -> Ok(())
    We’re using pactffi release 0.4.26 btw, am I missing something here?
    m
    • 2
    • 3
  • g
    Hey team, Im facing this error once I try to log in: 
    Error.
     
    412: We only support one authentication type at this time. Please try the type you used to sign up with.
    m
    • 2
    • 6
  • o
    Hi I would like to know if it is possible to configure Pactflow to automatically assign users to teams upon authentication via SSO, for example, using Azure Active Directory (Azure AD). The goal is for Pactflow to map the groups a user belongs to in the Active Directory (AD) during the login process, and based on that information, automatically assign them to one or more specific teams within the platform. This would allow the appropriate permissions and roles to be applied from the first login, without requiring manual assignments. Is it possible to enable this functionality to map SSO groups to Pactflow teams?
  • j
    Hi team, I’m looking for some advice on our current Provider's CI/CD setup with Pact Broker. We have two separate branches: 
    staging
    and 
    production
    , which may contain different code as features are tested in staging before being rolled out to production. 1. Would it make sense to maintain separate sets of Pact stages for each branch? 2. I've observed that when a webhook is triggered, the verification always runs against the main branch (staging), regardless of which branch initiated the process. This could potentially cause issues when the branches diverge. Any suggestions on how we can improve this setup or handle branch-specific verification more effectively? Thanks! Slack Conversation
  • a
    Hi. I have a json structure like this:
    Copy code
    {
  "data": [
    {
      "id": "123456789"
    },
    {
      "id": "111111111",
      "optional_stuff": {
        "data_map": {
          "blah_1": true,
          "blah_2": 123456
        }
      }
    }
  ]
}
    So my question is how to write the pact contract such that 
    "id"
    is mandatory but 
    "optional_stuff"
    is optional? At the moment I have to only specify the 
    "id"
    part as it's unclear if pact supports optional data.
    y
    b
    • 3
    • 4
  • t
    Hi, I think I have a common question but I couldn't find a guide for it so I decide to ask here. What should we do to write a consumer test for a retrieve endpoint that requires resource ID to be generated automatically on the provider side?
    b
    • 2
    • 3
  • j
    Hi, I'm currently using Pact Python v3, and I'm trying to implement consumer version selectors with a version for a specific consumer. However, I couldn't find any documentation or guides specifically for version 3. Is it possible to add a consumer version selector in this version of Pact Python? Below is the code I’m currently working with:
    Copy code
    verifier = Verifier().set_info(name=PROVIDER_NAME, url=PROVIDER_URL)
verifier.broker_source(url=URL(settings.pact_flow_url), token=settings.pact_broker_token)
verifier.set_state(url=PROVIDER_URL / "_pact" / "callback", teardown=True)
verifier.filter_consumers(consumer_name)
verifier.set_publish_options(version=str(version))
verifier.verify()
    Thanks for your help!
    y
    • 2
    • 2
  • a
    We have been using the pact-stub-server and found some serious performance enhancements. Is this the right place to discuss them? https://github.com/pact-foundation/pact-stub-server/issues/76 🙂
    m
    • 2
    • 2
  • p
    Hi This is pavanraj from atlassian, we have use-case of asynchronous api, 1. The api accepts the order and responds with 202. 2. Consumer polls on get order, based on the type of order placed, there will be fields set in the response. What is the recommendation for writing contract tests ? How do i get the confidence that any modification in order processing flow would ensure fields are populated as expected for the use-case ?
    b
    m
    • 3
    • 6
  • p
    👋 Hi everyone!
  • p
    Hi has anyone here ever renamed existing providers ? or has anyone ever provided providers that have no consumers ? So we have a microservice and therefore pacts were moved there. To know which contract belongs to whom we have changed the names. Unfortunately, I can no longer deploy or I can't do a can-i-deploy because there are no consumers or they simply still listen to the old providers. I wanted to ask how you deal with this?
  • p
    I should mention that the consumers are in other teams so I can't change them so easily
  • p
  • v
    Hey everyone I am looking for sample pact elixir project. I already searched in the pact-foundation repo But could not find it. Do we have any sample repo as example of pact API + async message working with Elixir? It would be great if anyone helps over here Thanks in advance.
    y
    • 2
    • 3
  • t
    Hello everyone, is there a recommended way to deal with Branches in Tag Pipelines? The GitLab Tag Pipelines have no branch name set. From what I have come up with I have two options: 1. Use the default branch name (which the tags are always made on). Then in validation pipelines that are triggered by webhooks I can check that out and reset to the tag. 2. Use no branch name. In webhook pipelines I would then checkout the tag detached. Are there any more consequences in using one or the other?
    m
    • 2
    • 3
  • a
    Hope you're doing well. We are currently working on improving how we visualize our contract test results. Specifically, we would like to build a dashboard that can display these results, broken down by the different teams involved. We are exploring options for tools or platforms that could help us achieve this. Do you have any recommendations or experience with tools that are well-suited for creating dashboards of contract test results, particularly those that can show results per team? Any suggestions or insights you could provide would be greatly appreciated. Thank you for your time and assistance.
    m
    • 2
    • 1
  • m
    Hi everyone 👋 Our team is considering using Pact for contract testing of message flows over Kafka and Apache Pulsar, while also leveraging the Schema Registry in both systems for schema validation ( with 
    BACKWARD
    compatibility type). Could you help clarify the main business cases for using both Pact and Schema Registry together? Specifically: • If we are already using the Schema Registry to enforce message structure and compatibility, does Pact contract testing become redundant? • Or does Pact provide additional value beyond schema validation? • If we decided to write contract tests for a Apache Pulsar messaging system, does Pact have any sort of integration - is it ready for that? (I wasn't able to find the necessary materials on this topic - everything is kafka centered 😅). Thank you very much for your insights!
    m
    • 2
    • 2
  • m
    📣 Introducing PactFlow’s AI Test Templates + 5 New Languages for Contract Testing AI Generation! 🚀 We’ve recently dropped a few major features to PactFlow’s AI capabilities that I wanted to share with you all: Test Templates and 5 new languages. If you’re using Pact regularly and are looking for ways to accelerate adoption across your teams, PactFlow’s AI features are worth checking out. 🎯*Key Capabilities and Benefits:* 1. Test Templates improves consistency and efficiency, reducing additional manual refactoring work + better “one-shot” test generation: a. Specify Code-Based Test Templates – Provide a local code-based template to use as a basis generated test output. b. Guided Templates – Include additional prompts or instructions to target additional use cases, or further customise output. c. RBAC Integration – Restrict template usage with PactFlow’s role-based access controls. 2. New Language Support - Generate tests in Go, .NET, Kotlin, Swift, and PHP, in addition to Java and JS/TypeScript. 📚 Dive Deeper • Documentation: https://docs.pactflow.io/docs/ai/ • Get hands-on with our workshop: https://docs.pactflow.io/docs/tutorials#use-test-templates-with-ai-augmented-contract-testing-in-pactflow 👉 Show me! Read the blog and watch a short video showcasing the feature: https://pactflow.io/blog/ai-test-templates/. AI features are enabled on all plans - including trials - if you’d like to test it out (start here). 🛣️ What’s next? We’re currently working on Code Review, and will soon turn our attention to MCP support (for better IDE, tool and agentic AI support). Have something you’d like to see there? Reply to this thread, DM me or create/comment on an issue on the roadmap.
  • j
    Not sure which channel this should go in, but I had a small issue with Pact using the Cypress adapter I had a question about. We use bi-directional contracts with Cypress to generate pacts on the frontend consumer. One of our providers uses a 
    API Base URL
    in their OAS. When we try to generate Pacts with Cypress for it on the frontend, the entire path (include that base URL) is provided as the consumer contract. The issue is, Pactflow doesn't seem to match it with the base URL and were having to strip it from the JSON before pushing it up to Pactflow. ie • Consumer pact states the path is 
    service/v1/endpoint
    • Provider states the base url is 
    service/v1
    and the endpoint is 
    /endpoint
    • Pactflow marks the two as incompatible UNLESS we strip the 
    service/v1
    from the JSON generated by the Cypress Pact adapter before we push it to Pactflow Any ideas of a better solution that stripping?
    m
    • 2
    • 2
  • e
    Hello, this is more about Contract testing overall. We have a pair of services that work together: an Ingress service (proxy), which provides authorization, and then an implementation service that does the actual work. Any client will simply call the Ingress service, which will authorize the caller, then pass the request along to the implementation service. From a contract testing standpoint, the general rule would be to define contracts between the outside consumer and ingress, and then between ingress and implementation. But practically, that doesn't really make sense. My general idea would be to treat the two services as effectively one service, but then I'm not sure how to set that up for proper testing. But one problem at a time. 🙂
    m
    • 2
    • 2
  • d
    Hi 👋, do we have any examples for pactflow contract tests kafka event driven systems using Python?
    m
    • 2
    • 3
  • z
    can someone help verify if the pact.io website is broken? Or is it just me
    https://pact.io/
    it seems like maybe the JS is broken on the page, and doing stuff like clicking 
    view on Github
    doesn't work for me
    m
    • 2
    • 6
  • b
    Hello, Is there a way to express that a response should contain a particular key, but that its value should be an opaque Json object? I appreciate that pact is not really designed for pass-through scenarios, but wondered if this could still be expressed.
    m
    • 2
    • 8