Hello, I am getting error "*must not have unevalu...
# pactflow
r
Hello, I am getting error "*must not have unevaluated properties*" in pact on validating against my schema. Attached sample of my schema and error I am getting. Please suggest some solutions. Thanks
m
r
I have used unevaluated property as true as per documentation but still getting issue as it does not identify this additional property on validator. Please help.
m
We don't allow unevaluated properties to be true. If we did, the validation would mean nothing
Can you please share the oas and pact file so we can better understand?
r
Get Endpoint Error - must NOT have unevaluated properties Consumer: [root].interactions[2].response.body.data.0.attributes = {"entity":{"type":"Equipment","id":"1234"},"isRoot":false,"name":"PointGroup Apiss 98"} In below part of provider schema I am getting this error. Provider Schema sample: PointGroupAttributes: additionalProperties: true allOf: - $ref: "#/components/schemas/PointGroupAttributesBase" - type: object properties: entity: type: object required: - id - type properties: id: type: string example: "entityId" type: type: string example: "Device"
m
How could I tell you if the snippet is compatible without the referenced schema?
r
This is the schema we are referring.
m
Thanks, it’s still a little tricky with the data you have given. It might be ideal you raise a support ticket so we can get an engineer on the case
howtopactflowsupport
s
Please create a ticket here with the issue details so that we can properly track the resolution and the PactFlow product support team will continue to work through it with you: https://support.smartbear.com/pactflow/message
m
It seems to be related to the
isRoot
property. There is hopefully a straightforward explanation for it, but it’s late and my brain isn’t working right now 😉
😄 1
r
I am also thinking the same but it looks correct for me not sure why it is creating issue. Created ticket for this 00560370
thankyou 1
m
Thanks, we’ll look into it
r
Do we have any updates on this issue ?
m
Yes, we’ll respond to the ticket. TL;DR - nested `allOf`s seem to be problematic. We’re not sure if it’s an issue with AVJ (the validator we use) or something in JSON Schema
r
okay
We are also facing one issue in pact related to oneOf in provider schema error: must match exactly one schema in oneOf consumer response: [root].interactions[9].request.body.data.attributes.configuration = {"binaryPointAlarmConfiguration":{"alarmValue":false}} Provider schema: (for full schema you can refer to schema I uploaded) Schema sample BinaryPointAlarmConfiguration: type: object properties: binaryPointAlarmConfiguration: type: object required: - alarmValue properties: alarmValue: type: boolean
m
Thanks. I'm actually wondering if we need to think about treating response bodies that use oneOf as any of because of this problem. I'll discuss with my colleague tomorrow
r
Hi, any updates regarding my issues ?
m
Hi Rajat, did you receive the response via our customer care team?
For now, we have provided a workaround for your
allOf
situation. We have some backlog items created to improve the experience, that we are reviewing in the next iteration. You will be automatically contacted via support when those features are completed.
Just coming back to this one Rajat. the
oneOf
issues you’re having, have you looked at adding a
discriminator
keyword: https://docs.pactflow.io/docs/bi-directional-contract-testing/contracts/oas/keyword-support/#the-discriminator-keyword? That would help narrow the chances of a schema conflict
a
Hi @Matt (pactflow.io / pact-js / pact-go). I believe the issue in our "*oneOf*" case - was not described correctly. Let me try to describe it. Here the starting point: We have a producer-contract (OAS) with endpoint POST /partition/{partitionId}/points/{pointId}/alarm-configurations using the "*oneOf*" statement *with 3 DISJUNCT schemas. (*So the schemas do not overlap.) We have written a consumer-contract where we provide a POST body, which matches exactly ONE of the 3 schemas listed in "oneOf" See the screenshot below, where the "binaryPointAlarmConfiguration" property is available in exactly one schema and in our consumer-contract body
The problem statement: When comparing the OAS and the consumer-contract body the pactflow.io console complains
"Request body is incompatible with the request body schema in the spec file: *must match exactly one schema* in oneOf
[root].interactions[7].request.body.data.attributes.configuration = {"binaryPointAlarmConfiguration":{"alarmValue":true}}"
Issue: But our POST body DOES indeed match to only one schema listed in "oneOf" statement. Only to the "BinaryPointAlarmConfiguration", as described in the above post. Question: Is that true, that the evaluation of pactflow.io does not perform as expected and that its a bug?
m
Thanks, and yes possibly. Any chance you could please provide a minimal version of your setup that induces the bug? We can then get it addressed
a
@Matt (pactflow.io / pact-js / pact-go) Hi Matt, attaching minimal version of the swagger and the payload cc/@Alex @Rajat Chouhan
m
I can’t reproduce the error you have with the files you have given. I have been able to produce a different error, but it would be ideal if you could please share a
payload.json
with the correct context (i.e. the pact you have generated, stripped down to the failing interaction only)
This being said, I did reproduce an
additionalProperties
failure:
Copy code
AlarmConfigurationAttributesGET:
      type: object
      required:
        - createdAt
        - lastUpdatedAt
        - message
        - category
        - enabled
        - configuration
      properties:
        configuration:
          # type: object # <- uncomment this and it fails 
          oneOf:
            - $ref: "#/components/schemas/AnalogPointAlarmConfiguration"
            - $ref: "#/components/schemas/BinaryPointAlarmConfiguration"
            - $ref: "#/components/schemas/MultiStatePointAlarmConfiguration"
        createdAt:
          type: string
          format: "date-time"
        lastUpdatedAt:
          type: string
          format: "date-time"
        message:
          type: string
        category:
          type: string
        enabled:
          type: boolean
This might be a bug, either in PactFlow, ajv (the schema validator we use) or just a misunderstanding of how
type: object
works.
You can test locally with this command:
npx @pactflow/swagger-mock-validator@latest test-swagger.yaml payload.json
Looks like we still have ticket #00560370 open with you. Can we please carry that there, otherwise we might double up 🙂
(I’ve asked for the ticket to go back to you to confirm the specific scenarios that are failing so I can have it investigated by a dev)
r
We are able to reproduce the error. Please use the attached point yml. Request body is incompatible with the request body schema in the spec file: must match exactly one schema in oneOf [root].interactions[7].request.body.data.attributes.configuration = {"binaryPointAlarmConfiguration":{"alarmValue":true}}
Unevaluated property is resolved but we are also facing
additionalProperties
failure and that existing 'oneOf' schema match issue. Should we raise separate ticket for additional property failure issue?
m
Do you have a corresponding pact for me to use also?
As per above
Copy code
AlarmConfigurationAttributesUpdate:
      type: object
      properties:
        configuration:
          #type: object <--------- 👋 this needs to be removed
          additionalProperties: true
          oneOf:
            - $ref: "#/components/schemas/AnalogPointAlarmConfiguration"
            - $ref: "#/components/schemas/BinaryPointAlarmConfiguration"
            - $ref: "#/components/schemas/MultiStatePointAlarmConfiguration"
Using my pact file from yesterday (above) and your points file, if I comment out the
type: object
where the `oneOf`s exist, this passes
Unfortunately the key engineer I need to explain to me why this matters (and if it’s a bug/expected) had to head on leave due to a family emergency, but when they return I will follow up. For now, that workaround hopefully should address your issue
r
okay I will try out with removing this and verify. thanks.
m
no worries, thanks!
r
By commenting those elements, the additional property issue is resolved. Then we are getting existing 'oneOf' matching issue described above.
m
Can you please share the failing test with the following command:
Copy code
npx @pactflow/swagger-mock-validator@latest <path to oas> <path to pact file>
r
attached the error of 'oneOf' match schema which I got while running by the command you provided.
m
Can you please share both of the files used in that command?
r
j
Hey @Matt (pactflow.io / pact-js / pact-go) could you share the
allOf
workaround your support team provided Rajat? Facing a similar issue in our implementation
👋 1
m
If it’s the same issue, where there is a
oneOf
, drop the
type: object
bit. I’m still figuring out why this works.
Copy code
AlarmConfigurationAttributesUpdate:
      type: object
      properties:
        configuration:
          #type: object <--------- 👋 this needs to be removed
          additionalProperties: true
          oneOf:
            - $ref: "#/components/schemas/AnalogPointAlarmConfiguration"
            - $ref: "#/components/schemas/BinaryPointAlarmConfiguration"
            - $ref: "#/components/schemas/MultiStatePointAlarmConfiguration"
@Rajat Chouhan I can reproduce the issue also. Please send that back to the original ticket. When the engineer working on it returns from leave, we will investigate. Thanks for putting that together
r
yes, already sent.
thankyou 1
🙌 1
a
@Matt (pactflow.io / pact-js / pact-go) Is there any update on this? We`ve bought the paid version since months but unable to achieve anything fruitful until now. Fast actions would be appreciated!
m
Surry Ankush, it looks like some of the history has been removed here. do you recall the customer care ticket number associated with this? I can then check to see. I believe it was fixed
r
@Matt (pactflow.io / pact-js / pact-go) Case #00560370 Still getting the same issue. Raised concern to the tool team. They are verifying.
m
Thanks, i’ll take a look today
Looks like there is still a bug there somewhere, i’ve passed it on to the dev team for review. Apologies for the hassle!