https://pact.io logo
Join Slack
Powered by
Hi all, trying to use pactflow bi-directional con...
# general
f
Hi all, trying to use pactflow bi-directional contract testing. And quick feedback. Please improve on the feedback you give back in relation to contract compatibility errors. How can teams verify why it's imcopatible when this is all the feedback the site give us? https://outsystems.pactflow.io/contracts/bi-directional/provider/poc-bi-cms/version/poc-[…]rations%3A2531%2CConfig_UnitTests%3A856/provider-contract
y
Hey, Thanks for the feedback, if you can request via #CLS16AVEE or on the public roadmap that would be great. RE: the error, see the changelog. We could probably point to that and update the troubleshooting notes if it occurs, so the the user knows the appropriate course of action https://docs.pactflow.io/docs/bi-directional-contract-testing/contracts/oas/changelog/#july-2023
f
the problem is that only that doesn't help whoever is checking the result. If at least it had the path to the property with that error, or the interaction that it failed
y
then please raise an issue with your expected outcome clearly laid out, and the team have something actionable that would satisfy your requirements 👍
m
Thanks for raising Fabio. It looks like this page could do with an update to explain this error more. Basically the OAS validator itself is failing to parse the document. Ideally it would give you a line number here so you can pinpoint the problem.
I’ll add it to our backlog for review. We are looking to overhaul the comparison tool under the hood, and this is something we could review at that time.
Unfortunately, avj (the JSON schema parser) doesn’t give us the line number IIRC
f
I just think it's bad that a quality tool has a failure response without giving line of what's wrong or more context on what was the problem. Worse, this fail all seem fine with the consumer contract but not having the contract validated. This is a Quality tool, and the premise of such tools is to give valuable actionable feedback. Nevertheless thanks for the actions taken
🙏 1
m
I understand and I agree, it’s not ideal.
Worse, this fail all seem fine with the consumer contract but not having the contract validated.
could you please elaborate on this also?
f
a lot of ambiguity here. So all interactions pass, but contract is not compatible?
so are we compatible or not? see what i mean
kinda like saying hot water is cold
so, i investigated further with this tool @redocly/cli and using it's swagger lint found this entry:
Copy code
[2] ..\OutSystems.ConfigurationManagement.Service\dist\openapi.v1.json:1488:25 at #/components/schemas/GenericConfig/properties/dataType/nullable

The `type` field must be defined when the `nullable` field is used.

1486 |   ],
1487 |   "description": "Type of the configuration",
1488 |   "nullable": true
1489 | },
1490 | "defaultValue": {

Error was generated by the spec rule.
so, i checked and got this from the swagger:
Copy code
"valueOrigin": {
            "allOf": [
              {
                "$ref": "#/components/schemas/Origin"
              }
            ],
            "description": "The origin of the value (e.g: Environment, Application, Library)",
            "nullable": true
          },
this is fine by openAPI 3.0 spec
worst part, this is a generated by code swagger file, not even created by hand
This is a important aspect, due to that we're checking if bi-directional contract testing supports a major part of our services/apps catalog, and we're checking if we can use this or we need to use other alternatives
Open in Slack
PreviousNext
Powered by