Pact verification of response body with XML content type fails on provider side due to example value (JUnit5)

[mhnot]

I tried to cover a XML file download endpoint via consumer driven contract test. I don't care about the downloaded content but want to verify that the body is not empty by using PactDslRootValue.stringMatcher("^.+$", "whatever")

Consumer class:

public class DownloadEndpointsCDCTest extends ConsumerPactTest
{
  @Override
  protected RequestResponsePact createPact(final PactDslWithProvider aBuilder)
  {
    final DslPart expectedBody = PactDslRootValue.stringMatcher("^.+$", "whatever");
    // final DslPart expectedBody2 = PactDslRootValue.stringMatcher("^.+$",
    //     "<?xml version=\"1.0\" encoding=\"utf-8\"?><example>foo</example>");

    return aBuilder//
        .given("A native production finished successfully")//
        .uponReceiving("A request to download a native")//
        .pathFromProviderState("/nativeresult/${jobId}", "/nativeresult/" + ChatTestUtil.DUMMY_JOB_ID)//
        .method("GET")//
		.willRespondWith()//
        .status(200)//
        .headers(Map.of("Content-Type", "application/xml"))
        .matchHeader("NATIVE-EXTENSION", "[a-zA-Z]{1,6}")//
        .body(expectedBody).toPact();
}

Generated contract:

{
  "consumer": {
    "name": "Core_Chat_Client"
  },
  "interactions": [
    {
      "description": "A request to download a native",
      "providerStates": [
        {
          "name": "A job finished successfully"
        }
      ],
      "request": {
        "generators": {
          "path": {
            "dataType": "STRING",
            "expression": "/nativeresult/${jobId}",
            "type": "ProviderState"
          }
        },
        "method": "GET",
        "path": "/nativeresult/dummyJobId"
      },
      "response": {
        "body": "whatever",
        "headers": {
          "Content-Type": "application/xml",
          "NATIVE-EXTENSION": "V"
        },
        "matchingRules": {
          "body": {
            "$": {
              "combine": "AND",
              "matchers": [
                {
                  "match": "regex",
                  "regex": "^.+$"
                }
              ]
            }
          },
          "header": {
            "NATIVE-EXTENSION": {
              "combine": "AND",
              "matchers": [
                {
                  "match": "regex",
                  "regex": "[a-zA-Z]{1,6}"
                }
              ]
            }
          }
        },
        "status": 200
      }
    }
  ],
  "metadata": {
    "pact-jvm": {
      "version": "4.3.14"
    },
    "pactSpecification": {
      "version": "3.0.0"
    }
  },
  "provider": {
    "name": "Chat_Service"
  }
}

Unfortunately the verification on provider side fails due to the expected body content "whatever".

 1.1) Content is not allowed in prolog.
	at au.com.dius.pact.provider.junit5.PactVerificationContext.verifyInteraction(PactVerificationContext.kt:66)
	at com.recommind.autotest.ContractVerificationTest.pactVerificationTestTemplate(ContractVerificationTest.java:145)

"Whatever" is just the example value for the body: PactDslRootValue.stringMatcher("^.+$", "whatever");_
I wonder that this definition is OK for the consumer side and that pact verification verification fails later on provider side.

Using the "expectedBody2" from the above example:
PactDslRootValue.stringMatcher("^.+$", "foo");
results also in a failure on provider side:

 1) Verifying a pact between Core_Chat_Client and Chat_Service - A request to download a native has a matching body
    1.1) body: $.example.#text Expected '' to match '^.+$'
	at au.com.dius.pact.provider.junit5.PactVerificationContext.verifyInteraction(PactVerificationContext.kt:66)
 at com.recommind.autotest.ContractVerificationTest.pactVerificationTestTemplate(ContractVerificationTest.java:145)

foo should also be just an example value.
How do I have to specify the expected body in order to just verify that it is not empty ?

Used versions:
Consumer: au.com.dius.pact.consumer:junit:4.3.14
Provider: au.com.dius.pact.provider:junit5:4.3.13

[rholshausen]

Fix released with version 4.3.16

[mhnot]

thank you @rholshausen
The new matcher works for us.