Hi, we spotted an issue that during provider verification slightly different request is replayed vs. the provider codebase than published by the consumer and visible in the Pactflow website. The problem relates to the situation when there is a numeric field in a request body, e.g.

{
  "quantity": 0,
  (...)
}

but a consumer defining pact using DSL put there a decimal matcher by mistake. In

Matching Rules

I can see

"$.quantity": {
            "combine": "AND",
            "matchers": [
                {
                    "match": "decimal"
                }
            ]
        },

instead of expected

"$.quantity": {
            "combine": "AND",
            "matchers": [
                {
                    "match": "number"
                }
            ]
        },

Then during provider verification following body is sent:

{
  "quantity": 0.0,
  (...)
}

which breaks our internal validations. It is hard to find the root cause since we expected that request body sent to our provider codebase is exactly the same as a request body published to the Pactflow but in fact it isn’t. Is it an intended behaviour or rather looks like a bug? FYI @Marcin Mosór

This sounds like it could be a bug in the underlying Pact SDK in the language of the Pact consumer. Would you mind sharing how that field is being defined on the consumer side in the relevant language's channel?

Hi @Joshua Ellis looks like a bug is located in Pactflow webpage. I checked a consumer’s codebase and the pact is defined as follow: • the value of

quantity

field is:

static final double QUANTITY = 0.00;

• in Pact DSL:

.decimalType("quantity", QUANTITY)

• finally in generated pact.json file:

"quantity": 0.0,

so the pact is generated correctly according to the DSL. On provider side the mechanism is also correct since

"quantity": 0.0,

is sent in a request body. However on Pactflow webpage it is visible as:

"quantity": 0,

which is misleading because this value is different that actual value defined in Pact file.