While I am asking questions actually, I may as well explain my true aim. In the metadata field of the request I want a nested object which will match when there are more keys than are specified in the contract. Currently I get this error from the matching

1) c9d8b50f42b5d1e7 - the following mismatches occurred:
        1.1) [] Expected metadata key 'headers' to have value '{"sec-websocket-protocol":"json-rpc"}' but was '{"connection":"upgrade","host":"[::1]:64257","sec-websocket-key":"qtwa71ue1dhx8b0ffbiqyw==","sec-websocket-protocol":"json-rpc","sec-websocket-version":"13","upgrade":"websocket"}' - Expected '{"sec-websocket-protocol":"json-rpc"}' to be equal to '{"connection":"upgrade","host":"[::1]:64257","sec-websocket-key":"qtwa71ue1dhx8b0ffbiqyw==","sec-websocket-protocol":"json-rpc","sec-websocket-version":"13","upgrade":"websocket"}'

The contract specifies the

"sec-websocket-protocol":"json-rpc"

header, but the request comes in with a lot of others. We only need the one header validated in the contract. The connection request we are establishing has the header and it has the correct value so this should pass. However as the contract doesn't contain all the other headers it fails. I'd like to make the matching work like the header matching in HTTP contracts, however I want the headers in an object called headers and not on the root of the metadata object. This is because we are now trying to add query params as well and I'd like to keep the two separate.

This would need changes in the Pact libs. I think it treats the metadata as a flat collection.

At the moment it looks to me like the metadata is treated how I want my nested property to be. i.e. it ignores unexpected keys. This seems to be coming from the

DiffConfig::AllowUnexpectedKeys

on the matching context. However nested values are compared with Equality. So it would be great if we could apply the DiffConfig setting at least one level down. Also it seems impossible to actually change the matching context for metadata at the moment so if we wanted a different behaviour on metadata we wouldn't actually be able to do it. Although isn't a feature we actually need so not too bothered about that