Hi, I has (trimmed and reformatted, not real structure) consumer test like this:

pact.addInteraction({
            states: [...],
            uponReceiving: '...',
            withRequest: {...},
            willRespondWith: {
                status: 200,
                headers: {...},
                body: {
                    min: 1,
                    'pact:matcher:type': 'type', // I am aware that I'm using custom version of `eachLike`
                    value: [ // NOTE example value has 3 values, not 1 when we use `eachLike`
                        {
                            id: uuid(id),
                            father: uuid(father),
                            mother: uuid(mother),
                        },
                        {
                            id: father,
                        },
                        {
                            id: mother,
                        }
                    ],
                },
            },
        });

Now provider response body (trimmed and reformatted, not real structure) look like this:

[
  {
    "id": "79c4b8d7-5224-32cf-8ff1-ef0bcaedc1e3",
    "father": "f897f1b7-3867-318c-9f34-06480ffd0fab",
    "mother": "7973a31e-856e-3940-acbb-9e21e7f627bf",
  },
  {
    "id": "7973a31e-856e-3940-acbb-9e21e7f627bf",
    "father": null,
    "mother": null,
  },
  {
    "id": "f897f1b7-3867-318c-9f34-06480ffd0fab",
    "father": null,
    "mother": null,
  }
]

I expected provider's verification will failed (because matching rule

uuid

on

father

and

mother

), but it still passed. Do you know why?

I’ll have to check Tien. I wonder if it’s the non standard use of the eachLike matcher that’s causing the issue. What happens if you remove the second and third object in the consusmer test? (so that the example only has items with

uuid

matchers?)

If I remove other example values (except the first one), provider verification failed as expected.

1) Verifying a pact between admin and relationship Given Users with full information - get list users with full information
    1.1) has a matching body
           $[1].rels.mother -> Expected '' to match '[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}'
           $[1].rels.father -> Expected '' to match '[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}'
           $[2].rels.father -> Expected '' to match '[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}'
           $[2].rels.mother -> Expected '' to match '[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}'

I’m assuming it’s taking the matching rules from the last example you gave it, rather than the first. But we shouldn’t allow multiple different examples (i.e. in index 0, all three items have matchers, in index 1 and 2 there are no matchers at all, and there is only one valid property:

id

I compared 2 versions of the generated pacts, and they are exactly the same (including

matchingRules

), except the example values I removed of course

interesting!

you can occasionally supply invalid values to a matcher definition (i.e. incompatible with the matcher)

I believe we need to handle this one in ffi library, not in every languages that use it? Should I create a bug for it, for pact-reference project, with my example code/information?

Yes please!

And I believe my situation will never happen because ffi library will refuse to generate the pact at the first place