Making a separate thread for verification discussion @Yousaf Nabi (pactflow.io)

Yeah interesting use case. I agree that if you filter the contract contents you aren;’t checking that the provider can provider everything exactly as the customer has specified it, and therefore a verification result here is deemed as full, even though in reality its a partial. Equally, if the provider utilises requestFilters and modifies the request, they potentially augment the consumer request. I wonder if there is a use case for a coverage metric or some way of saying that • x amounts of interactions are tested • x amount havent • x contract was augmented at verification with a can-i-deploy being able to use that as a confidence level.

Equally, if the provider utilises requestFilters and modifies the request, they potentially augment the consumer request.

This shouldnt’ be a feature

Eg, in message queues, you could deploy safely without the provider being deployed

Yep, so in that scenario depending on the setup, the consumer just emits a message and its never picked up, or it may not be picked up but then sent a DLQ where it could be picked up later

My view is that it just needs per-interaction information: • Needs {provider / consumer} to be present before deployment • This interaction may be optionally verified (which means that it can be missing at verification, but if present it must be working)