A dumb question may be : we are trying to help a client implement contract testing and they have thrift protocol between services is what I understand. Can somebody please explain the relevance of contract testing in such a situation? @Yousaf Nabi (pactflow.io) @Matt (pactflow.io / pact-js / pact-go)

Hey all, small question, but our provider contracts have an issue per pactflow:

Cannot read properties of undefined (reading 'type')

but thats all we get for the error message. Does any stacktrace or line number exist for this error? Having trouble going though the provider contract to find the issue.

@Ruth has left the channel

@Cody Jenkins has left the channel

👋 I need to establish a conformance certification program around an OAS that will have three conformance profiles related to three subsets of the overall OAS (forecast, real-time, and peering). I need to be able to certify conformance of multiple implementations of the OAS, and I'd like to be able to provide the conformance test suite to implementors for their use in their own CI/CD pipelines. (Part of the conformance suite will be a data file that represents that provider state at the beginning of the test.) I don't have a mandate to build clients or a provider, but I think I will need to build at least the latter of those to develop the conformance profile tests. Each of the profiles will need to ensure the successful execution of a handful of scenarios. A primary consideration is the DevEx of the provider implementors. In particular, I want it to be easy for them to understand why a particular scenario is not passing; some scenarios may involve a series of API calls so being able grok the overall journey is important. I am also concerned about sustainment: HTTP, JSON, and OAS were safe, accessible choices with long-term ecosystems. Relatedly, I need something that is "free-as-in-beer", even if the project is ultimately able to fund some quality of life improvements in the toolchain. There's more than one way to do it, as they say. I've looked at Karate, Hoppscotch, Postman/Newman, and Insomnia/Inso. They all seem plausible. My gut tells me that I want the provider contracts to live as independent artifacts of equal importance alongside the OAS itself. More to the point, since the OAS was developed spec-first instead of TDD/BDD-style, I'm quite certain developing the provider contract will identify gaps and other failings in the design, so I'd like to iterate the OAS and the contracts together until 1.0. Would you have any advice to give?

Hi all Is verification of XML responses in the roadmap? If not is there a way for us to build that feature ?

@Alejandro Sanchez Giraldo has left the channel

@Evan Rademacher has left the channel

@Taha Shakibania has left the channel

@PK has left the channel

Hello people, My project uses FastAPI and OpenAPI schemas. Can someone recommend what library or libraries I should use with these? Any leads are highly appreciated.

Hi, I wanted to ask if it would somehow affect the licensing terms and how you would feel if I made a public repo(fork) where the following GitHub actions work with the OSS PactBroker (no need to use PactFlow) https://github.com/pactflow/actions I understand it's an unusual question, but I wouldn't want to proceed in conflict with the PactFlow org.

@Diego Betancur has left the channel

Hi all I am experiencing an issue with

discriminator

I have the following example schema:

components:
  schema:
    full-request:
      title: Full request
      description: This is the full request
      type: object
      properties:
        type:
          description: Type of request
          type: string
        payload:
          description: Request payload
          type: object
          oneOf:
            - $ref: '#/components/schemas/ORIGIN_A'
            - $ref: '#/components/schemas/ORIGIN_B'
          discriminator:
            propertyName: originator
      required:
        - type
        - payload
    ORIGIN_A:
      type: object
      schema:
        allOf:
          - $ref: '#/components/schemas/common'
          - type: object
            properties:
              originator:
                const: ORIGIN_A
              originatorId:
                $ref: '#/components/schemas/origin-id'
            required:
              - originator
              - originatorId
    ORIGIN_B:
      type: object
      schema:
        allOf:
          - $ref: '#/components/schemas/common'
          - type: object
            properties:
              originator:
                const: ORIGIN_B
            required:
              - originator

Pactflow is not able to handle the discriminator in this case, I get the following message:

discriminator: oneOf subschemas (or referenced schemas) must have "properties/originator"

Looking through the docs I can't understand why that isn't working.

Btw it would be great to add support for discriminator

mapping

Hey there, from https://pactflow.io/gdpr-dpa/ I get that PactFlow seems to be hosted on American AWS Servers entirely. If a company for legal reasons needed to keep the data within Germany for example, would there be a possibility to get a PactFlow instance hosted in Germany?

@Megan Honig has left the channel

@Blake Norrish has left the channel

Hi team, I recently worked on a pact test instance with a service provider where they don't have true provider tests and that raised concern regarding the process of setting up a webhook. My understanding is that when working with open api swagger docs, a webhook is not feasible and also not needed. The service providers have a setup where a provider contract publish job is run with each merge to the api doc repo (when updating api docs). I'd like to get validation that based on this setup, validation would occur when we would want it to, every time a pact changes.

hey folks, general question really, I know you have AsyncAPI on your roadmap, do you have any more specifics on when/if that is gonna be focused on anytime soon?

[Best practices] How many contract tests should one endpoint have? What criteria should I have to asses? complexity? stability? Let's consider phases of Contract Test intro in ecosystem: 1. getting started, onboarding new service 2. New contract in onboarded service 3. business as usual, securing service

[Introducing Contract Testing] The most popular question before, or even after the Pact is implemented:

Is that really worth it to invest in Contract tests?

That's from people who understand contract testing, and are aware that this is limited to checking the contract only. How would you respond?

[Feature Toggles] I can't figure out how recording deployments on envs and Can I Deploy work with feature toggles? The use case I have trouble with is when: 1. consumer has a pact towards provider checking 20 APIs and is on prod 2. Consumer adds 21st interaction with same provider and wants to deploy to prod but with a feature disabled by the feature toggle for this single new API. 3. therefore on prod this api will never be called, but the whole rest of other APIs in pact should be validated. 4. Consumer in main branch already satisfies the contract but is not on prod yet How to 1. deploy the consumer to prod

Hi team, I’m curious about the future plans for pact-php. Specifically, I’d like to know if there’s any roadmap or timeline for supporting v4 of the Pact specification directly in pact-php. Additionally, is there any plan to make v4 support available without relying on beta features or the FFI wrapper? It would be great to understand how this aligns with the broader vision for Pact language support. Looking forward to your insights!

Hi team, We currently have an account on CICD(codefresh) that used to be managed by a former employee that is being used to execute contract testing on our pipelines. • Is there a way that we can convert that existing account into a service account instead? • What would be the alternative? I see that system accounts can be created. Would that be the same as a service account? Looking forward to hearing back. Thanks!

Hello folks! The documentation states that “Pact may not be the best tool for testing pass-through APIs like BFFs”. I can understand the reasoning behind that, but as almost all FEs I’ve seen in the past years (mobile or Web) talk to the BE via some Gateway, how can we use Pact in the FE to ensure that the contracts between FE and BE are in sync? What kind of pitfalls would I fall into if I decide to add Pact between my FE (mobile and web) and my GW, and another one between my GW and the actual BE service? Thank you for your thoughts!

hey guys, does

@pactflow/pact-cypress-adapter

support only pact-specification v2? if yes, is there any way or workaround to use pact-specification v4?

Why do you need it to support V4?

[Best Practices] Setting states on provider can be a nightmare for a provider to manage when overused by consumers. How to manage setting provider states at scale?

@Spencer has left the channel