One scenario here is server-driven HTTP contracts - in Pact, consumer is kind of a synonym for client. But, generally, it might not be - for example, a consumer of http requests

This is a departure from the way that pact does it, where “consumer” is kind of a synonym for client, and “provider” -> server. With this slight change to the model, you’re defining (and testing) what you consume, and describing what you expect to provide: HTTP client-defined test: • I will provide this request • I can consume this response HTTP server test:: • I can consume this request • I will provide this response SQS message receiver test • I provide a poll to get a message • I can consume this message SQS message sender test • I provide this message • I consume nothing (or, I consume a “sent successfully” SQS API response- but this wouldn’t be in the client)

I think it’s best-practice to do client-driven tests, but with this model you can trivially do server-driven tests

I’d like for it to play nicely (and natively) with the Pact broker. What I was planning to do was say that the system that wrote the contract is the “consumer” and the system that reads/verifies the contract is the “provider”. But, if I do that, I’m concerned I’ll run up against this deployment-zero problem, where the “provider” can always deploy without the consumer - but that might be a broken state.

Even if I hadn’t changed the definition of consumer/provider (slightly), I think this problem still exists - as above, it exists with messages (where a consumer will be blocked when it shouldn’t be), and I think it will also exist with gRPC (depending on the types of gRPC supported)

Is it worth raising a feature request for this? During contract definition, you would always know if either end could deploy without the other - so it could be recorded in the contract. But this wouldn’t work for providers that have never run verification (because they don’t have any contracts yet)