skip to content

In Pact, what does a pending pact change about the provider's build, and how do WIP pacts go further?

level: middleimportance: nice to knowfreq 27%

answer

  1. the broker decides this, not your test
  2. still replayed, just not fatal
  3. one of the two widens the net
  4. a date bounds how far back
  5. it disarms itself once satisfied

basics

~20 s

A pending pact is one this provider has never successfully verified, so its failures are reported without failing the provider build. WIP pacts go further: they pull in consumer pacts the provider would not otherwise fetch, and are pending by definition.

solid answer

~40 s

The **Pact Broker** marks a pact pending when that exact pact content has never been verified successfully by a provider version on the branch the provider is building. A pending pact is still fetched, still replayed and still reported in full - it simply cannot fail the provider's build, so a consumer can publish a new expectation without turning somebody else's pipeline red. Once the provider satisfies it and publishes the result, the pact stops being pending and later regressions do break the build. **Work-in-progress pacts** go further: they ask the broker to include never-verified pacts the provider's normal selection would not fetch at all - a consumer's feature branch, for instance - bounded by a since-date. Every WIP pact is pending by construction, so widening the net is always safe.

code

java · 9 lines
java
@Provider("grant-portal-api")
@PactBroker(
    url = "https://broker.internal",
    enablePendingPacts = "true",
    includeWipPactsSince = "2026-08-01"
)
class GrantPortalPactVerificationTest {
    // the @TestTemplate verification method is unchanged
}

go deeper

for a junior

Recall only that a mechanism exists to stop a brand-new consumer expectation from breaking a provider team's build, and that it stops applying once the provider satisfies that expectation once.

for a middle

Explain who computes the pending mark, that a pending pact is still fetched and replayed in full rather than skipped, and what work-in-progress inclusion adds on top of it.

for a senior

Be ready to say why a pact failing quietly as pending for weeks is an organisational failure, and why the whole mechanism silently never arms if verification results are not published back.

for a principal

Own the rollout across many providers: when to enable these, what since-date to standardise on, and how to stop pending becoming a permanent excuse rather than a temporary courtesy.

## What pending means, and who decides it Pending is a property the **Pact Broker** computes; it is not a flag the provider's test sets. When a provider asks the broker for pacts to verify, the broker answers with each pact plus a note saying whether that exact pact content has ever been verified successfully by a provider version on the branch this provider says it is building. If it never has, the pact comes back marked pending. The verifier honours that mark. It still fetches the pact, still applies the provider states, still replays every interaction, and still reports every mismatch in full. What it does not do is fail the build. A pending pact that fails is loud in the output and invisible to the exit code. Two conditions have to hold for this to work. The feature has to be switched on for the run - in Pact-JVM through the `enablePendingPacts` attribute on the broker annotation, in pact-js through the equivalent verifier option. And the run has to tell the broker which provider version and which branch it represents, because "has this ever passed?" is meaningless without a baseline to ask the question against. ## Why the provider's build is the thing being protected The problem pending solves is organisational rather than technical. Without it, a consumer team that adds an expectation the provider does not yet satisfy turns **somebody else's** pipeline red the moment they publish. The provider team, who changed nothing, now owns a broken build. The predictable response is a rule that consumers must not publish new expectations until the provider is ready - which destroys the point of consumer-driven contracts, where the consumer's expectation is supposed to be the thing that starts the conversation. Pending inverts that. The consumer publishes freely, the provider sees the new expectation in its build output as information rather than as an incident, and red-build pressure arrives only once the provider has honoured the contract at least once. From that moment the pact is no longer pending, and a regression against it fails the build like anything else. The safety net removes itself. ## Work-in-progress pacts go one step further Pending changes what happens to a pact the provider **already fetches**. Work-in-progress pacts change **which pacts are fetched at all**. A provider's normal selection is deliberately narrow - the pacts belonging to the consumer versions it cares about. A consumer experimenting on a feature branch sits outside that set, so their new expectation is verified by nobody until it lands. Turning WIP on asks the broker to additionally include never-verified pacts from outside that selection, bounded by a date: only pacts created after the configured since-date are swept in. Every WIP pact is pending by construction, so widening the net can never turn the provider red. | | Pending pacts | Work-in-progress pacts | | --- | --- | --- | | What it changes | Whether a fetched pact can fail the build | Which pacts are fetched in the first place | | Applies to | Pacts the provider's selection already includes | Never-verified pacts outside that selection | | Bounded by | Verification history for that pact content | A since-date, plus verification history | | Stops applying when | That content verifies successfully and the result is published | The same | | Primary beneficiary | The provider team's build stability | The consumer team's feedback loop | ## Whose problem each one solves - **Pending is the provider team's protection.** Their pipeline stops being hostage to other people's in-flight expectations, and as a direct side effect the consumer team is unblocked from publishing at all. - **WIP is the consumer team's feedback loop.** An expectation still living on a feature branch gets replayed against the real provider automatically, so the consumer discovers whether the provider can satisfy it *before* merging - without asking the provider team to add a selector for a branch that will exist for four days. Neither is a substitute for the other, and enabling WIP without pending is incoherent: the whole reason it is safe to widen the net is that everything caught in it is non-blocking. ## Practical cautions - **Choose the since-date deliberately.** Without one, enabling WIP sweeps in every never-verified pact the broker has ever stored, including abandoned branches from teams that no longer exist. The day the team switches the feature on is normally the right date. - **Pending is not a licence to ignore output.** A pact that has been failing as pending for six weeks is a conversation nobody is having. The mark suppresses the exit code, not the responsibility. - **Pending depends entirely on published verification results.** The broker only knows a pact has passed because some provider told it so. A pipeline that verifies but never reports back leaves every pact pending forever, and the build-failing behaviour everyone believes is protecting them never arms at all. That is the single most common way this mechanism is misconfigured. - **Do not confuse a pending pact with a pending test.** A test framework's pending test is not executed; a pending pact is executed in full and simply cannot break the build.

  • When does a pact stop being pending?
    Once a provider version on the provider's own branch verifies that pact content successfully and the result is published back to the broker. From then on the broker no longer marks it pending, and a later regression against it fails the provider build like any other test. The safety net removes itself the moment the contract is genuinely honoured - which is exactly the behaviour you want.
  • Why does work-in-progress inclusion take a since-date?
    It bounds the blast radius. Without a date, switching WIP on would sweep in every never-verified pact the broker has ever held, including contracts from abandoned branches and teams that no longer exist, so the provider's build output fills with noise nobody owns. The date says only contracts created after this point are my problem, and the day the feature is enabled is normally the right choice.
  • Can pending pacts hide a genuine regression from the provider team?
    Not for an established consumer. A pact whose content has already been verified successfully is not pending, so breaking it still turns the build red. The real risk is different: if a pipeline verifies but never publishes results, nothing ever leaves pending status, so every contract failure stays non-blocking indefinitely and the gate everyone believes in never actually arms.

A pending pact is an alarm on probation: it is wired up and it rings for everyone to hear, but it is not yet connected to the fire brigade - and it gets connected the first time the building passes inspection.

saying these in an interview costs you the question

  • Thinks a pending pact is skipped rather than replayed
  • Believes pending pacts stay non-blocking forever
  • Confuses a pending pact with a framework's pending test
  • Enables WIP with no since-date and drowns in old contracts
  • Says the provider's test sets pending, not the broker