I'm embarking on upreving pact in a variety of consumers and providers, and have a general question about how to handle breaking changes in pact itself. For example, somewhere between pact-jvm 4.2 and 4.6 there appear to have been changes in the handling of how timestamp match assertions are serialized and verified. This can cause providers using the older release to fail verifications against pacts published by consumers running the newer release. Of course for main branch provider verification, the answer to this is to uprev support in the provider too. However, a lot of pacts recommended CI/CD workflows and webhook triggers don't just verify on latest from main branch; verifications often scope wider to already released versions too. For example, if the currently released version of the provider is based on 4.2, the new consumer's contract will never be successfully verified by that version of the provider. The problem is that this verification result is a "false negative". If I'm trying to ensure my new consumer can deploy alongside the currently released provider, not only does it tell me wrongly that it can't, but it also effectively masks any actual verification issues which might exist between the 2 pacticipants. So I'm interested in advice on how best to deal with such situations.

Yeah, that’s tricky. The issue I know you’ve experienced appears to be a bug that was fixed in later versions, but the result is that you now have a behaviour change that is problematic. More generally, you could expect other similar bug fixes (or indeed, just bugs) that could cause this deadlock situation.

When verifying a previously released version of a provider that has a "problematic" pact dependency version, its baked into the sources that the verification pipeline will check out. For example with maven builds the pact dependencies will be defined in the

pom.xml

that gets checked out. I can think of 2 possible ways around this... 1. Override Dependencies in the Build In that particular case I guess it might be possible to override the pact dependencies from the commandline if you can spot you are dealing with an older version e.g.

mvn test -Dversion:io.quarkiverse.pact:quarkus-pact-consumer=1.3.0 -Dversion:io.quarkiverse.pact:quarkus-pact-provider=1.3.0 ...

However, there might be issues with this if e.g. the old provider is on a JVM version earlier than the new pact dependencies. 2. Intercept and modify pact This approach would require some kind of pact pre-verify hook that could declared outside of code; knowing the problematic changes in the pact JSON, one could write a simple e.g. regexp that ran on a downloaded pact prior to verification. The new pact could then be "downgraded" to an equivalent that induce a false negative verification result.

Yeah, (2) is not an entirely bad idea but currently would be hard to achieve as you’d need a hook in the DSL. It can be done manually (i.e. download the pact, modify it, verify it) but that may escape the logic that sends verification results back to the broker (I don’t know how Pact JVM under the hood fetches pacts and sends results back, and if any local files that had the HAL resources in them would be sent back to the broker)