For BDCT, we're having some trouble figuring out this error.

Response body is incompatible with the response body schema in the spec file: should NOT have additional properties - id
Mismatched Pact Path:
[root].interactions[0].response.body.paymentMethods[0]
Mismatched Provider Path:
[root].paths./userprofile/v1/paymentmethods.get.responses.200.content.application/json.schema.properties.paymentMethods.items.additionalProperties

In our provider contract, if we follow the provider path, items can be

anyOf

, as seen below

responses:
        '200':
          description: Successful response
          content:
            application/json: 
              schema:
                type: object
                properties:
                  paymentMethods:
                    type: array
                    items:
                      anyOf:
                        - $ref: '#/components/schemas/creditCard'
                        - $ref: '#/components/schemas/bankAccount'

 schemas:
    creditCard:
      type: object
      properties:
        id:
          type: integer
        userId:
          type: integer
        externalId:
          type: string
        type:
          type: string
        lastFour:
          type: string
        isPrimary:
          type: boolean
        issuer:
          type: string
        verificationStatus:
          type: string
        expiration:
          type: object
          properties:
            year:
              type: integer
            month:
              type: integer

We're wondering why the contract comparison can't find the schema definition?

paymentMethods[0]

is matching the credit card schema currently in our consumer contract As an aside, should BDCT questions be in #C5F4KFKR8 or #CLS16AVEE (since it's currently just a pactflow feature)?

Hey, some pointers here in the docs https://docs.pactflow.io/docs/bi-directional-contract-testing/contracts/oas#allof-support-and-other-logical-keywords Have you got the ref snippet for bankaccount? If it differs, your provider could only ever provide one response, and your consumer could require both, or one. BDC questions are best asked in here but appreciate it can be confusing, and some OSS users prefer not to see Pactflow messaging in general. I never minded personally prior to joining the team, but can appreciate and understand. Do you think a bi directional slack channel would be useful, especially given it is a big feature, and new so there is lots of overlap and interesting conversation that would be nice to group

Thanks for the response @Yousaf Nabi (pactflow.io). Yes, the bank account object is different

bankAccount:
      type: object
      properties:
        id:
          type: integer
        userId:
          type: integer
        externalId:
          type: string
        type:
          type: string
        lastFour:
          type: string
        isPrimary:
          type: boolean
        issuer:
          type: string
        verificationStatus:
          type: string

Since Pact does not support those key words then, I assume we just don't want to contract test those use cases then? Or is there another route we should go? I think a separate BDCT channel would be super helpful since it is a big feature and the documentation is still limited

Are you able to use CDCT with the traditional pact verifier flow on this endpoint or are you looking at BDCT only? With Pact CDCT, you can control the behaviour of the your provider, with provider states which would give you finer grained control of the provider response. You can run the bi directional validator locally, where you can control the flags to perform different validation behaviours. Pactflow is opinionated about its choice of flags, to prevent breaking changes that were not caught by the default behaviour of the original Atlassian tool. https://www.npmjs.com/package/@pactflow/swagger-mock-validator Not sure on the best advice at the moment but will noodle with the team and get back to you.

We really should be able to support the

anyOf

and

oneOf

operators. Unlike the

allOf

which I think is more problematic (albeit we could modify the behaviour to suit the standard use case), I think the validation behaviour is clearer

Is there any update on the direction for this?

It's been added to our backlog for review. Officially we'd like to be able to support it

We’re running into the same thing now - a large swagger def. of 16k lines with 150 uses of

allOf

in, is there any update or sense of timescale for this being reviewed? Thanks 🙂

It’s currently on the prioritised backlog if issues to solve around the new launch. I can’t give timeframes at this stage.

Thanks for your replies, we’re going to look at the

json-schema-merge-allof

solution I think, and accept that the OAS file we push to the broker isn’t quite the original

Thanks - feedback on that would be great

yea, depends how agressive / opinionated the lib is in how it generates it’s output - gotta try it to see i guess!