I have a consumer deployed to environment env1. The consumer (ver-x, branch-x) contract expects a GET query like this:

{
  "param1": [
    "2"
  ],
  "param2": [
    "abc"
  ]
}

I have a bi-directional setting between my provider and my consumer. I have intentionally changed the provider (ver-y, branch-y) API to not be compatible to the consumer (ver-x, branch-x) contract by offering only the parameter param1. But when I publish the provider swagger.json file, the interaction consumer contract (ver-x, branch-x) vs provider (ver-y, branch-y) is shown as compatible and green. And when I execute can-i-deploy provider (ver-y, branch-y) to env1, the command passes and allows me to deploy the provider. Shouldn't a provider API which misses some of the parameters the consumer expects, be considered as incompatible to that consumer? What could be the reason why my interaction is evaluated as compatible by Pactflow?

Hi Cyrus, Currently this is considered a “warning” but that warning is not shown in the PactFlow UI. It is because query parameters are a special case. The original authors of the tool we use in the BDCT workflow reasoned as follows:

The reason we didn’t do this in the first place is it becomes a blocker for fast 5 style changes where the consumer deploys first. For example if we wanted to add a new query param to an API in a world where unknown query params were disallowed then the provider has to change the Swagger file as the first step. Our thinking was that in general more teams would prefer the flexibility to deploy in any order over the strictness.

We have created a tracking item to revisit this decision, in light of this report and real-world usage. I’m assuming you have found this behaviour surprising? Might I ask a follow up question. In your case, what is the impact of the provider not supported that query param? Does it simply filter the response or does it change the behaviour of the API in a way that would result in breaking the client?

Hi Matt, thank you for your explanations. Do I understand you correctly: You refer to query parameters as a special case among the following ways parameters can be passed from a consumer to a REST API provider: header parameters, cookie parameters, path parameters, query parameters, body parameters, matrix parameters, form parameters, and plain parameters? Yes, I found this behavior surprising because if I remember correctly, the last time I was experimenting with Pact tests involving missing parameters on the provider side, Pact would not accept such cases. I'm pretty sure this was the case in a consumer-driven test setting. However, I was under the impression that I also saw the same behavior in a bi-directional test setting a few months ago, but I'm not sure about that. I might be hallucinating. But in our case, if the consumer were to send a request with two parameters to the provider that only supports the first parameter, the provider, as it is right now, would return error 500. I guess that wouldn't be the filtered response you were referring to. However, our system is in the prototype stage, and I don't think the behavior of our provider could be seen as particularly mature at this stage.

Thanks for the explanation, this will be helpful as we consider the implementation

Than you very much for your explanations. By the way, is there any way to see/get that warning you mentioned before?

Not in the Pactflow UI sorry