pactffi_message_reify has different schema between v3 and v4

[adamrodger]

When you call pactffi_message_reify on a v3 of v4 pact you get a totally different schema back:

v3:

{
  "contents": {
    "foo": 123
  },
  "description": "a message",
  "matchingRules": {
    "body": {
      "$": {
        "combine": "AND",
        "matchers": [{
          "match": "type"
        }]
      },
      "$.foo": {
        "combine": "AND",
        "matchers": [{
          "match": "type"
        }]
      }
    }
  },
  "metadata": {
    "contentType": "application/json"
  }
}

v4:

{
  "contents": {
    "content": {
      "foo": 123
    },
    "contentType": "application/json",
    "encoded": false
  },
  "description": "a message",
  "key": "42505f05e4db2bf1",
  "matchingRules": {
    "body": {
      "$": {
        "combine": "AND",
        "matchers": [{
          "match": "type"
        }]
      },
      "$.foo": {
        "combine": "AND",
        "matchers": [{
          "match": "type"
        }]
      }
    }
  },
  "metadata": { },
  "pending": false,
  "type": "Asynchronous/Messages"
}

This makes writing integrations in wrapper libraries much more difficult - I've now got to know which version of the interaction the user has set up in order to deserialise it properly to create the message inside consumer tests. I may need to release a breaking change of PactNet to support that, which I really want to avoid.

[rholshausen]

Those formats are different. As per the definition:

reify \RAY-uh-fye\ verb. : to consider or represent (something abstract) as a material or concrete thing : to give definite content and form to (a concept or idea)

What you are asking for is the opposite, an abstraction over the differences between V3 and V4, and pactffi_message_reify is not the function to do that.