Provider side matching is not working if I add any thing or rename or remove any field in request body of provider which is not same as contract then its not failing.
Eg inside contract file request body contain name field and the same field if I remove or rename in request body of provider (not in response) only in request then pact is not validating that.
I want to confirm at provider side will the matching work on request body?
I can see matching rule for request body in pact file but its seems like not functioning.
Adding new fields into a provider response that is not required by a Pact contract is simply ignored.
Why is this the case? Pact follows Postel's Law. Unexpected elements in a response should not cause issues for a consumer. Other consumers may have different but overlapping needs, so failing a provider build on these grounds is problematic.
From our docs, what this translates to:
Be conservative in what you send - when the mock server in the consumer project compares the actual request with the expected request, the actual request body is not allowed to contain fields that are not defined in the expected request body. We don't want the situation where our real consumer is "leaking" data that we don't know about.
Be liberal in what you accept - when verifying a pact in the provider project, the response body and headers may contain fields that were not defined in the expectations, on the assumption that any extra field will be ignored by your consumer. This allows a provider to evolve without breaking existing consumers (unlike the bad old WSDL days).
To your second point:
I want to confirm at provider side will the matching work on request body?
It sounds like it is working. It's correctly identifying breaking changes if you change the datatype, or have an unexpected response code.
If you rename a field that is required by a consumer, then that sounds like a bug (a fatal one in terms of Pact features, so I'm skeptical).