Pact Foundation

Hi Pactflow team,
Our bi-directional contracts started failing with no changes on our side. I found that changes to <https://github.com/pactflow/swagger-mock-validator/pull/38|how you deal with additionalProperties> got released recently. I don’t quite understand how to fix that on our side though. We don’t set `additionalProperties: false` in our schema, should we do it on each object type to be able to pass validation now?

for more context:
we do have fields like `properties` or `metadata` where we expect any field to be send and we store the object as is later in the db.
Now all such fields trigger compatibility errors `must NOT have additional properties` even if I explicitly set  `additionalProperties: true`

additionalProperties can also accept a schema of allowed types, have you considered this case?

It's a tricky problem. We've seen a lot of examples where it's set to true but for bad reasons.

We may need to consider allowing an application to configure that behaviour

&gt; additionalProperties can also accept a schema of allowed types, have you considered this case?
yeah, but it’ll be a temporary solution for us as if tests start sending different fields in the object (and we don’t care that they change), we will have to update provider contract again.
As I still want to test such a field and have a stable contract, I’d like to have a way to say “ok, I know the risks, please apply additionalProperties: true”

thanks for your reply! I’ll apply your suggestion

I think I’ve created a type that will work for you. I’ll publish an example shortly

I’ve also realised you’re sending this on the _request_ side - the change above probably is most impactful on the response side. The issue is it’s hard for us to detect if it’s in a `definition` - it could be used in both contexts.

See this example here: <https://github.com/pactflow/bdct-oas-examples/tree/main/examples/additionalProperties>

I think this expresses a JSON type that is equivalent to `additionalProperties: true` .

Thanks a lot for the example <@U9UUY3CU9>!
&gt; I’ve also realised you’re sending this on the _request_ side
yeah, that’s true. anyway it’s the part the response side is responsible for. so, it does make sense to update the provider’s contract.

You’re welcome - do you think it will help?