Just checking my understanding - am I right that t...
# pact-broker
t
Just checking my understanding - am I right that the broker can store arbitrary json contracts, but only one per service pair? like, if I have: ServiceA (@ v1.0.0) -> ServiceB, and I publish a contract of one type, I can’t publish another contract between ServiceA (@ v1.0.0) with ServiceB without overwriting the first one?
m
yes that’s right. The contract can be any JSON, but the model is that it contains everything needed by that consumer version of a given provider.
t
Right. That’s what I thought. It’s a shame, because all the merge-contract-file problems go away if you let multiple contract files be published for the same version
Maybe I’ll request it on Canny
Maybe you’d have other problems. Hmm.
m
That might be a separate concern (publishing vs the relationship itself) but logically there is one contract. The broker does have a feature to merge a contract on upload, it's not well advertised/ used however
One problem I envisage would be knowing when you have all of the interactions covered in a verification or can-i- deploy scenario race condition.
👍 1
t
The broker does have a feature to merge a contract on upload, it’s not well advertised/ used however
I don’t think you could do this without knowing the semantics of the contract, right?
m
I think it merges it remotely using the same business rules as if it were set to
merge
. e.g. it will continue to append interactions, until it sees a conflicting interaction (I believe by uniquely identifying them based on description, state and possibly http bits).
but yes, effectively it must know something about the type of contract - that is, a pact file
b
I don’t think you could do this without knowing the semantics of the contract, right? (edited)
Correct - merging pacts is one of the pact specific features. It was added to support the scenario where JVM tests were split across different nodes running in parallel. I don’t advertise it because it’s a pain to support and introduces all sorts of problems with webhooks.
I encourage people to merge them on the client - the pact publication CLI does the merging client side before it publishes them, if it finds pacts with the same consumer/provider/spec version.
At one stage I was working on a design to allow multiple contract types per version, but ron decided it would be better to merge them into one pact file, and support that in the pact specification.