As you can see, the consumer contract is comparing...
# pact-broker
j
As you can see, the consumer contract is comparing the FULL path of the request to the partial path in the provider contract (the full path being made up of that server url + the endpoint). Is there something I should change to how I'm uploading the pact on either the provider or consumer side to resolve this?
b
Best to ask in the #CLS16AVEE channel, as the Pact Broker doesn’t support bi-directional contracts.
👍 1
@Candy Goodison do you have any thoughts on this?
m
It’s possible the server URL is not taken into consideration during the matching. We could potentially look to do this, albeit it’s possible to have multiple server URLs defined so that would have other impacts for consideration
I would suggest for now to pre-process your pact file to strip those paths out (or update the OAS, but I’m guessing that is less preferable). We could potentially also allow the Cypress adapter to do that (e.g. define a base URL that is removed from the serialisation)
👍 1
c
yeah that is exactly what I am thinking too matt, the server urls may not be being taken into consideration
t
If this is using the swagger-mock-validator, I believe it just directly compares the paths 😕
b
Oh, I understand the problem. When it’s deployed, you put an extra path at the start of the API path.
So the consumer contract has a contract for the deployed path, while the provider contract only knows about its pre-deployment path.
☝️ 1
Interesting.
t
That's my understanding too. I think in the Pact, the full path is there, but in the OAS, it isn't (because OAS has a "server base url" concept)
b
yeah. interesting.
t
the provider contract only knows about its pre-deployment path.
I think the provider contract knows
{some_base}/path
👍🏼 1
b
I’m not sure which bit should have the understanding of that.
I feel like this should be an option passed into the oas/pact verifier.
t
I agree. I don't like the idea of
{some_base}
because it doesn't give you deployment confidence. So, I feel like ideally it should be an input into the validation
b
I’ve only ever seen servers defined with a host, not with a path, but it makes sense that it’s a Thing.
m
Yes. The issue is the provider contract (for an OAS) can have multiple servers and each server may have a differ base URL. The results for these could be different of course so that would be another set of rules we'd need to think about
t
It's common with an API gateway consuming a bunch of services that are defined by OAS
☝️ 1
b
I think this is a feature request for the oas/pact verification feature.
💯 1
m
Yep
Or at least further consideration
b
yes, definitely worth hashing it out and thinking through the implications.
👍 1
m
I'll pop an item in the backlog. For now though stripping the base URL before publication is your best bet Jordan
j
Sounds good, thanks for all the input everyone!
🙌 1