Hi everyone, I need some help understanding the relationship between the "Pending Pacts" feature described here and the "pending" field that can be configured inside the "interactions" section of a contract definition. You can see it here . From the "Pending Pacts" documentation, I understood that the pending status of a contract is calculated automatically and dynamically by the Provider (as explained here ). Because of this, I cannot understand if or how the "pending" field inside the interactions is considered, since it can be set by a Consumer when defining a contract. What am I missing? Thanks a lot.

You’re right, it is a bit confusing. The broker does have a pending pacts feature, and it is dynamically calculated. The proposal for the V4 spec was to allow users to mark tests explicitly as pending (see https://github.com/pact-foundation/pact-specification/issues/73#issuecomment-1728673538). There is a feature spec for it in the core, but I’m not sure how the broker behaves if it sees this I don’t think it’s actually in any clients yet either. cc @Joshua Ellis @rholshausen

Hi @Matt (pactflow.io / pact-js / pact-go), thank you for your reply to my message. This question was raised by one of our teams implementing consumer contract tests in a repository managed with Trunk Based Development. Therefore, they were expecting to be able to mark those tests as pending so they could freely merge into main and continue deploying their application, even if the provider isn't ready to satisfy the contract yet (since they use Trunk Based Development, deployment and release are managed separately and safely via feature flags). Currently, however, their consumer cannot be deployed anymore because can-i-deploy is preventing them. The consumer test is being written in Rust with pact-consumer version "1.4.2" and v4 specs, which, as you can see here, already support the pending definition in the interaction part of the consumer test. So, they are wondering what that field is supposed to do 🙂

can-i-deploy and the Broker are at fault here, they don't support that field.

Thanks Ron, that’s what I thought might be going on. What is sent back to the broker for interactions marked as pending? The way pending pacts works today, is that if a consumer interaction is marked as pending (i.e. it’s new to this branch of the provider) it won’t break the provider verification, but the consumer’s can-i-deploy checks will still fail. The broker needs to understand that if the interactions are explicitly marked as pending by the consumer, then they should be ignored in can-i-deploy checks regardless of the result of the provider. This is presumably the work that needs to go on (and is likely non-trivial, as I think it through)

Thanks for all the info. Just to let you know, we don't have an on-premise version of the Pact Broker since we use PactFlow. I didn't catch whether we are discussing a missing feature not yet implemented in the Pact Broker managed by PactFlow or a faulty implementation (bug). Could you clarify that for me, please? Thanks a lot.

It just hasn't been added to the broker (or Pactflow) yet. The specification can be ahead of implementation and this looks like one of those cases

OK, understood. Is there a way I can monitor the implementation of that feature on PactFlow? Just to stay up to date without bothering anyone? 😅

Thanks. I’ve created https://github.com/pact-foundation/pact_broker/issues/885 to track

Thanks 🙏🏻

Once it's in broker it'll flow to PactFlow pretty quickly