Adam Rodger

I think if we're going to do this then the release notes and comms to client library maintainers need to be improved as a prerequisite. Probably also the FFI needs...

It's a weird chicken-and-egg thing, because effectively you want to test pre-release versions of the FFI against all the client libraries to spot any issues early, but the client libraries...

Yeah that's why it needs to be at 1.x first though. You don't need to bump the major version just to deprecate something, but you do need to raise a...

For example, if you try to deserialise the provider state body that's POSTed to `DIctionary`, you get really awkward types in the values. You can't do something like this: ```csharp...

I think the problem must be something like here where it tries to match interactions based on their key: https://github.com/pact-foundation/pact-reference/blob/master/rust/pact_models/src/v4/pact.rs#L365 My interactions don't explicitly have keys (I've no way of...

I've recreated the problem at least as far back as FFI 0.4.0. I'll keep going back as far as I can until I can't reproduce

I've also recreated in FFI 0.3.13, but the difference there is that the Pact file outputs a unique key for each interaction (hence why they're not matching). I remember a...

#264 was the issue I was thinking of where auto-generation of keys was removed. I'm not sure if there are still problems in here though, or whether it's the fallback...

Yeah I can't see the problem just from looking at the code and the Pact output. The `key` field is missing from the messages so those both must be `None`,...

The attached commits suggest that the interactions need to have a unique description, but the merging behaviour compares the description, provider states and interaction type as the unique identifier of...