Hello I have a provider with an API method which accepts a POST query with the following request body:

{
  "recipients": [
    {
      "firstName": "string",
      "lastName": "string",
      "emailAddress": "string"
    }
  ],
  "subject": "string",
  "content": "string"
}

And I have a consumer which sends a request to the provider with following request body:

{
  "Content": "<h1>test</h1>",
  "Recipients": [
    {
      "EmailAddress": "<mailto:test@test.com|test@test.com>",
      "FirstName": "Test",
      "LastName": "User"
    }
  ],
  "Subject": "Test subject"
}

I'm trying to have Pact based bi directional contract testing working between these two apps. When I publish both the provider OpenAPI definition and the consumer pact, Pactflow complains about the consumer pact being incompatible with the provider. The message is like this:

Incompatibility With Provider Contract

Request Body Is Incompatible

Request body is incompatible with the request body schema in the spec file: should NOT have additional properties
Mismatched at:
[root].interactions[0].request.body

I manually changed the pact file to have properties starting with lower letters and then published the manually modified pact file and then Pactflow was happy and there were no more errors about incompatibility. My question is, can this case sensitive behavior be disabled by some configuration option? Thanks

We don't have an option, no. Case is important, is it normal that your code send requests with the wrong case?

Well the request body is generated from a class with that same structure. And because its a C# class it is upper camel case. On the consumer side the class is converted to Json and the upper camel case name remains like that. But the swagger.json API defintion on the provider side generates lower case properties. I guess thats normal behavior of Swashbuckle package that generates the swagger.json API definition. Of course its not a big issue, I can declare the properties as lower case like this:

[JsonProperty(PropertyName = "subject")]
public string Subject { get; set; }

But because the communication is not affected by these case differences, the real communication between the provider and consumer works despite different case types, I wondered whether it would be possible to make Pact a bit less restrict. Maybe Swashbuckle could be configured to stop changing the case type of properties involved.

EmailAddress

!=

emailAddress

though? What would your provider do if it got a POST request containing

{
  "firstName": "string",
  "lastName": "string",
  "emailAddress": "string",
  "EmailAddress": "anotherstring",
  "eMailAddreSS": "someotherstring"
}

or

{
  "firstName": "string",
  "lastName": "string",
  "emailAddress": "string",
  "eMailAddreSS": "someotherstring"
}

Your OAS that is generated should match that of your application, if it isn't you should configure an option in it, or programatically change it after, there are plenty of tools designed to manipulate an oas spec, otherwise you could easily write a tool to do so. Otherwise your clients e This is a topic on the swashbuckle repo on the subject https://github.com/domaindrivendev/Swashbuckle.AspNetCore/issues/383 You shouldn't be changing pact files manually, as they match your clients issued request, and expected responses which are important. Therefore it is equally important that your provider spec, matches it's implementation

Aha, so it should be possible to resolve the issue on the Swashbuckle side. I have to give it a try. Thank you very much for the link you posted.