Hi Team, I recently updated my PACT broker to late...
# pact-broker
a
Hi Team, I recently updated my PACT broker to latest and after that started seeing the below error if I run the same build twice with same version and sha value. Is there any way to override this error ? I have to do the fake commit in my builds to fix this issue so that the sha value gets changed.
Copy code
14:50:49  r6mE7ZKysbDjBMD6lurpN0xZ | {"notices":[{"type":"error","text":"Cannot change the content of the pact for label-svc version 2.4.0.ffc70b7 and provider label-svc, as race conditions will cause unreliable results for can-i-deploy. Each pact must be published with a unique consumer version number. For more information see <https://docs.pact.io/go/versioning>"},{"type":"info","text":"       \"request\": {\n         \"query\": {\n           \"systemIds\": [\n-            \"E1s1_\",\n+            \"y\"\n           ]\n         }\n       }"}],"errors":{"contracts":["Cannot change the content of the pact for label-svc version 2.4.0.ffc70b7 and provider label-svc, as race conditions will cause unreliable results for can-i-deploy. Each pact must be published with a unique consumer version number. For more information see <https://docs.pact.io/go/versioning>"]}}
Thanks.
m
Yes, Have you read the link in the error?
It explains the problem and what you can do about it
a
@Matt (pactflow.io / pact-js / pact-go) Yes it says use the git sha which I am already doing. So whenever we do a commit sha value will change and it will not give any error but if we rebuild in that case git sha will remain the same what we have to do then ?
Let me know if I m missing anything here
m
The issue is that your pact file is changing
My guess would be that you’re using matchers and not providing example values, and they are being populated with random values and therefore changing
the broker provides a way to see a diff between versions: https://docs.pact.io/pact_broker/advanced_topics/see_changes_pact
a
Ohh k got it. Thanks I will see the diff between versions.
t
My guess would be that you’re using matchers and not providing example values, and they are being populated with random values and therefore changing
Aside, but shouldn’t it… not do this?
Wouldn’t it be better to have the random examples generated at verification time? Since the contract is “this bit is <any string>”
a
@Matt (pactflow.io / pact-js / pact-go) I have hardcoded the values now in request query params instead of using matchers and the issue is resolved. https://docs.pact.io/pact_broker/advanced_topics/see_changes_pact This helps me in finding the exact difference what was coming in the PACT. Thanks a lot.
👍 1
m
Aside, but shouldn’t it… not do this?
Yes, I’ve argued this point also, but there are some APIs in Pact JVM that would require deprecation for this to happen. In any case we have matchers that don’t accept examples, the example is always a hard coded value, not a generated one
Wouldn’t it be better to have the random examples generated at verification time? Since the contract is “this bit is <any string>”
yes. These matchers existed before the concept of generators though. It’s actually a much simpler problem than generators - it’s just that the implementation uses random strings, rather than hard coded ones. Probably that would be the way to resolve this (that way the API hasn’t broken). It’s possible of course people have relied on the random behaviour (aka Hyrum’s Law)
b
How’s this:
Copy code
Cannot change the content of the pact for %{consumer_name} version %{consumer_version_number} and provider %{provider_name}, as race conditions will cause unreliable results for can-i-deploy. Each pact must be published with a unique consumer version number. Some Pact libraries generate random data when a concrete value for a type matcher is not specified, and this can cause the contract to mutate - ensure you have given example values for all type matchers. For more information see <https://docs.pact.io/go/versioning>
👍 2
t
I like this. I think it would be improved if there was a separation between the key error message and the advice (and perhaps the advice could be made into dot points). This would make it more robust to skim reading