Hey all, I'm looking for some feedback on our pact setup and how we can avoid a particularly sharp edge that we recently bumped into. We have a single consumer and provider pair with pactflow acting as broker. I added a PR to our provider codebase to support an upcoming pact release (consumer version 0.7) that we were planning to do. Once that was merged, we then manually verified that our 0.7 pact verified successfully against the provider locally, then marked the 0.7 pact as released. Provider builds continued to verify as normal. However, provider branches which diverged before the PR to add 0.7 support was merged are now failing to verify, since they don't have the PR to support 0.7. What we really want is to verify that the outcome of merging this branch to main will verify successfully, not that if we shipped this branch to prod verbatim it would verify successfully. Rebasing those branches onto main then caused the verification step to pass, since they now included the PR to add support for 0.7. Is it possible to avoid this scenario so devs aren't blocked by failed builds? So far we have a couple of ideas: 1. use a merge queue to confirm that a merged branch will verify, 2. only run verify when the PR diff looks like it changes the API endpoints. Neither of which are particularly appealing at this stage, so happy to hear if there are any other options!

then marked the 0.7 pact as released. Provider builds continued to verify as normal.

the consumer app or provider app? I’m confused about which one was deployed

So we released version 0.7 of the consumer, which released version 0.7 of the pact, causing provider CI builds to verify it.

Yeah, that’s tricky.