Hi everyone, I noticed a strange behaviour when us...
# pact-jvm
s
Hi everyone, I noticed a strange behaviour when using regex matchers using the 4.3.5 JVM DSL. When using Regex then PACT is generating random values that are compliant to my Regex, but.. they are random. This leads to the issue that the broker is unable to cache my PACTs and when re-running the consumer PR pipeline on the same commit than before, it looks like I get a merge conflict in the broker (due to the random generated "discountPrice"). Is this a bug? If not, we should certainly extend the Javadoc of all regex matchers for the JVM module to clearly point out that this does generate Randoms, because the javadoc at the moment does not state this :) The reason why we retry the consumer PR pipeline on the identical PACT version is this: When a changed PACT is not yet ready to merge because the provider doesn't support it yet, my PR is blocked for merging. As soon as the provider has built the changes and published his verification results, I as the consumer, have to rerun my PR pipeline on consumer side. I don't want to have the necessity to push a dummy commit though.
Apart from that, generating random values when using regex matchers seems to contradict the PACT rule of thumb, to not use randoms. For us it seems like, that we have to discourage the usage of Regex matchers in general now, because every PACT using regex matchers is appearing as a new PACT in pactflow for every commit I suppose, even though nothing really changed syntactically?
I mean generating a random is fine to have "something" in the PACT that conforms to the Regex. But the output of the randomizer has to be consistently identical when recreating the PACT and this is not the case (i see that locally)
Here's my output when running twice:
m
Most matchers have the ability to specify an example to accompany them, thus removing any randomness.
Check if there is a method overloaded
You're right though, I would discourage random values
s
Hi Matt! Thanks for quick response. Indeed there is a method overload to provide our own. But I believe this is an easy trap and its going to be quite hard to understand the reason of these merge issues, or, it works and causes unwanted side effect behaviour. Since this method is in now we cannot remove it, but may I suggest / contribute a javadoc change on the method level to indicate the randomness explicitly with reference to pact Docs?
message has been deleted
I'd even think about a Randomizer algorithm that generates consistent randoms, so that when run twice, the output is identical. I'll note it on my list.
j
Hi Matt, thanks for your response. My question would be if there is a use case for regex matcher to generate an example? Maybe it would be an option to simply remove that functionality and let the user supply a sensible example?
m
All good points. There may well be but I've not encountered one before. @uglyog might have some use cases for it that would explain its existence
r
It's historical. Earlier versions people wanted to use random values in their tests. It has been replaced with generators, which generate the random value at runtime and not persist it in the Pact file
👍 1