We're trying to use the generated pacts from pact-jvm-consumer-groovy using pact-foundation/pact-stub-server.
The problem is that the generated pact will add and empty string "" in the matching rules for path, which seems incorrect per V3 specification. In the pact-stub-server, the request won't match
"matchingRules": {
"body": {
},
"header": {
"Authorization": {
"matchers": [
{
"match": "regex",
"regex": "Bearer .*"
}
],
"combine": "AND"
},
"X-Correlation-id": {
"matchers": [
{
"match": "regex",
"regex": "[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}"
}
],
"combine": "AND"
}
},
"path": {
"": {
"matchers": [
{
"match": "regex",
"regex": "/order/[^/.]+/shipping"
}
],
"combine": "AND"
}
}
}
If we change path to:
"path": {
"matchers": [
{
"match": "regex",
"regex": "/order/[^/.]+/shipping"
}
],
"combine": "AND"
}
}
It will work. We checked the code and it looks like it will be always adding an empty entry when recording the expectation, independently of the jvm-consumer
Created the issue here as it seems more relevant to how all jvm-consumers are writing the pact file.
Confirmed it is an issue with Pact-JVM.
I've also updated the pact stub server (v 0.0.10) that will handle the invalid matcher format.
awesome! Thanks @uglyog! Looking and learning with the commit, next time I'll try to fix it myself
Version 3.5.21 has been released
Most helpful comment
I've also updated the pact stub server (v 0.0.10) that will handle the invalid matcher format.