Hey good people, i have a consumer contract that that has a regex matcher in expectations (for a pre-signed url). What the consumer is expecting is a pre-signed s3 url. Before it was in a format like:

<http://s3:9000/tenantdata/tenants/00000000-0000-0000-0000-000000000001/applications/dda8be6e-e132-4892-a441-63b3a30bfaff/s>

but recent architectural changes have made us to change the url format to a new one

<http://s3:9000/plat-t00000000000000000000000000000001/applications/dda8be6e-e132-4892-a441-63b3a30bfaff/sourcecode-d281f084-1666-3fa4-06ce-1a1214d3692c?X-Amz-Expires=600&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=accessKey1/20220216/us-east-1/s3/aws4_request&X-Amz-Date=20220216T123217Z&X-Amz-SignedHeaders=host&X-Amz-Signature=fb7b255661baa9ebeb991a8a2f16a7f8e93f9a978eeca129a534c89255bca838>

Now the consumer side already changed the matcher in code and published the new contract in CI to pact-broker but is still giving up the old matcher and thus our provider test fails. We are already asking for the latest version by the way. Does the mechanism that pact-broker uses to check if it's a new version of the contract take in account the matchers or it just takes in account changes in keys

@Beth (pactflow.io/Pact Broker/pact-ruby) may correct me here, but I think it detects a new version based upon the pact contract itself, so if you've changed the consumer tests and published a new contract then that should be the latest version. You can use the HAL browser on Pact Broker to explore and find what different versions it thinks exist.

ok, thanls

Are you using tags or other ways to differentiate pacts? Using only latest will lead to these problems because builds run all the time across different branches etc

yep, that wa what happened. Another PR rewrote (with the old definition ) the contract, and thus the fail