Hi Where in current new UI there is an option we can turn on "allow dangerous contract modification" We found that during reruning of PRs the publish consumer contract task step is constantly failing is it is showing that contracts were not change and have race conditation. Is there any better way to handle that ? maybe there is an option to detect contract which were not changed and delete them or just overwrite ? https://docs.pactflow.io/docs/troubleshooting/disabling-dangerous-contract-modification

have you got random data in your pact? you can’t do it via the UI https://docs.pactflow.io/docs/troubleshooting/disabling-dangerous-contract-modification#disabling-dangerous-contract-modification-1

actually it can be done via pact api ?\

From the docs, you need to request it from the team, as it isn’t a customer enabled option for SaaS

anyway can this problem be solved if i will remove hardcoded guids from contract and just make it random one ?

are you currently using

uuid()

in your code? That will generate a unique uuid each time. I think you should be able to provide a example, which means you will get a uuid matcher, but a fixed value that is used for contract comparison (ideally you want the fixed data, so that the pact can be pre-verified if those contents have already have an existing verification)

those hardcoded guids are jsut used in URI

the 2nd screenshot shows a uuid in the resp body that would be random each run (I believe)

it should 🙂 im wondering how to tackle that problem as it starting to fail our releases constantly now, when people are keep reruning pipelines

don’t use random data, as advised in the docs. use a fixed uuid in the response

ok but anyway how for know that problem with race conditions on PR re-run we can solve ?

That might be a separate problem, what is the particular problem you are seeing with race conditions and I can certainly try and help

so when we raising PR to develop it trying to publish consumer contract into pactflow.

I would normally advise semver-<commt_sha> so pacts are traceable to commits

so for example you propose to use this as a version ? https://www.npmjs.com/package/absolute-version?activeTab=readme

you can use the

auto-detect-version-properties

flag which will pick up the git commit / branch and build url for you, if you use the cli

auto-detect-version-properties - what is this and where it lives ?

i found

it will generate a unique version number, every time you commit your code and the build runs. retrying builds won’t be affected, as you will solve the random data problem (by using fixed uuid in response, or providing a example value) at the moment, I believe you have clashes between builds, because they use the same version number (if I do two commits on the same branch and push each commit seperately, I should expect two unique version strings, to Pact, even if your apps semver is still the same) the build url, is the url to your build job on your ci server, in your case azure. Pact is aware of the environment variables in several CI systems. When you view the contract version in pactflow, you will see a url which links back to the job in your ci system that created it

just wondering what that will change, as we passing this semversion anyway which is unique

yes add as a new value there, it will overwrite the

--consumer-app-version

value. the issue with the version as semver. if you take main and create two branches, with two different changes, both minors. they will both have the same version, but potentially different contents, if both of them change an api client and therefore pact, if different ways. also you are on a single branch, each commit might not change the semver value, but have different pact contents. this would stop you being able to overwrite the contents, as you would be publishing to the same semver version

BTW we fixed issue by fixing those random values in tests.

just wondering what that will change, as we passing this semversion anyway which is unique

semver doesn’t imply unique across commits. i.e. multiple commits might contribute to a semver release - you should use the git sha as the version (or incorporate it into the version, with your semver version). This way, each build won’t result in publishing over a previous version. This leaves you with the scenario of re-running an existing build for a particular version (e.g. a flaky build or something). That’s when you can address it with reducing random data in your tests

about issue i have following : `Error making request to https://XXXXXX.pactflow.io/provider-contracts/provider/XXXXX-API/publish status=409 {"title":"Conflict","type":"https://problems-registry.smartbear.com/already-exists","detail":"A provider contract for XXXXXXX-API version 1.141.0-PullRequest32608.39 already exists with different content and may not be modified. You will need to delete this resource and re-publish it. You can delete the resource by opening https://XXXXXXX.pactflow.io/hal-browser/browser.html#https://orbus-d99fe527.pactflow.io/contracts/provider/Orbus-Infinity-API/version/1.141.0-PullRequest32608.39 in your browser, clicking on the

NON-GET

button for the

self

relation, and sending a

DELETE

request to it.","status":409,"instance":"/","errors":[{"detail":"conflicts with existing value","pointer":"#/contract/content"}]}`

IT is happening when for example pipeline fail and will be re-runned

there reason that is happening is that you must have some dynamic values in your pact test, which means if you re-run an existing pact suite the generated pact changes. This is why you hit that problem. The solution is to find any dynamic values and make them statit

Yes thank you for all answers, problem with OAS spec is probably because of random GUIDs genereted per each build.

Is this a consumer or provider contract?

Yeah ive managed to fix it