Hello! We have a use case where a group of contracts between a consumer and a provider are not valid anymore and need to be deleted. Deleting them from the code was not enough to inform the broker that these contracts would be deleted and not to be validated in future checks. Is there a programmatic way to do this other than manually deleting the contracts from the broker UI or API?

No, you would need to delete the integration via the UI or API

you could make a set of api requests to call the same endpoints being invoked by the manual deletion via the via, and pass your creds in the header if your broker is authenticated

I'm interested in how this situation arose . . . was a consumer (or provider) decommissioned? Would any other scenarios would leave behind unwanted contracts or dangling pacticipants?

@Boris it rose because of functionality at the provider's side that got decommissioned

As in, not a whole contract, but just some interactions disappeared?

yes exactly. the provider used to have a functionality to do something and it does it not have it now

That sounds like a regular Pact case, and you need a strategy to remove the dependencies from the contracts.

No, the pacts were already deployed to the broker, but now that the functionality is removed, the pacts are as well removed from the code, the broker still has the old pacts as active, and when the provider runs its test, it is failing because it's trying to verify them.

Just to clear up some terminology • the pact file is a contract artifact (the actual contract is conceptual) • the contract is made up of interactions • the contract is published to the broker • the consumers and providers are released & deployed to environments

Okay, given this terminology, I'll state the chronological order of the events: 1. the provider had a functionality to do some operation 2. the consumer started using this functionality, so they wrote a pact file for it, then generated the contracts and published them to the broker 3. the provider then started validating these contracts each time they deploy? 4. later, the provider stopped supporting this operation, hence the consumer had to delete these pact files 5. the contracts, however, are not automatically deleted from the broker, so the provider's tests are failing since PACT is trying to validate the old decommissioned contracts

So, 1, 2, 3 sounds good 👍

If that's not happening, you may be generating them with a merge strategy, instead of cleaning up the old interactions

so you're saying, if the consumer stopped using a functionality, hence removed its pact files from its side and deployed to the broker, the new version of the contracts on the broker should squash the old one, i.e. the provider won't need to validate the contracts of the mentioned functionality anymore?

It's not really about the files, it's about the tests that generate the files. But the rest of that sounds right 👍

consumer-driven

ok, cool . . . otherwise my knowledge might not be all there 😅

hahaha no it's alright. Thanks a lot!

All g, I hope it's a bit easier to follow now 🙏 You definitely want to be clear about the separation between: • the tests, • the interaction each of the tests describes, • the contract (Pact file), made up of interactions for a consumer-provider pair

yes. Thanks for the clarification! made it much clearer.

so you’re saying, if the consumer stopped using a functionality, hence removed its pact files from its side and deployed to the broker, the new version of the contracts on the broker should squash the old one, i.e. the provider won’t need to validate the contracts of the mentioned functionality anymore?

pact file = all of the interactions between a given consumer and provider pair. interaction = test case (basically) a. If the consumer no longer talks to the provider, you need to delete the integration from the Broker b. If the consumer no longer needs some of the interactions, the pact file should still be generated and sent to the broker, sans the interactions no longer required. It sounds like the scenario you’re running into is (b). If so, it sounds like you might not be using the most recent guidance for our CI/CD workflows (seen here: https://docs.pact.io/pact_nirvana)

thanks for the insight! I will definitely checkout the mentioned guidance