<#CLS16AVEE|> Response Body is incompatible with t...
# pactflow
v
#CLS16AVEE Response Body is incompatible with the response body schema in the spec file: should NOT have additional properties - PhoneAddress Mismatched Pact path: [root].interactions[0].response.body.UpdatedContact.ContactPoint mismatched Provider Path: [root].paths........................schema.properties.UpdatedContact.properties.ContactPoint.additionalProperties My provider response object contains in this format: Body: { "UpdatedContact": { "ContactPoint":{ "PhoneAddress": { "code":"+77", "phoneNumber":"1234567" } } } } My spec for the following is below attachment in a truncated format:
m
Hi Venkat, I can already see at least 2 discrepancies: 1.
PhoneAddress
defined twice 2.
PhoneAddres.code
is used, but in the definition it’s
PhoneAddress.internationalCode
Could you please ideally share a full working (or in your case, failing) example that we can review?
👀 1
One guess (you could try):
Copy code
EditCustDetailsContactPoint:

      type: object # <- try commenting this out

      properties:

        ContactPoint:

          anyOf:

            - $ref: '#/components/schemas/VerifyEndpointPhoneData'

            - $ref: '#/components/schemas/VerifyEndpointEmailData'
🙌 1
v
Thanks Matt, Will sort the first comment For EditCustDetailsContactPoint, actual type was not there but later added. let me check again.
👍 1
PhoneAddress.code was my typo...sorry for that.
👍 1
@Matt (pactflow.io / pact-js / pact-go) I think the spec is missing this discriminator keyword as we are using anyof openAPI schema https://docs.pactflow.io/docs/bi-directional-contract-testing/contracts/oas/keyword-support/
It turned out that the discriminator is for oneOf not for anyOf.
m
It turned out that the discriminator is for oneOf not for anyOf.
correct. It’s to discriminate distinctly between 2 or more schemas.
anyOf
doesn’t care if it matches multiple
v
Thanks @Matt (pactflow.io / pact-js / pact-go) Now it brings back the question "What is making the error by PactFlow"
m
I believe it’s a known issue with the
type: object
and keywords. Were you able to confirm the suggested fix above worked?
v
We removed type:object but it didn’t work. If we remove anyOf , it is working but the provider is not going to change that.
m
of course
OK, i have reproduced the issue
the good news is that that’s actually fixed in the latest version of that code
🙌 1
the bad news is that it’s not yet released to on-prem
the redeeming news is that it’s not too far away (probably < 1 week)
🙌 1
v
Wonderful, thanks for your prompt attention. Atleast we know the issue and resolution.
❤️ 1
m
No worries. I’ll respond to your email ticket now also