I'm trying to add v4 support to PactNet and I've got in a real mess when I try to use it for real at work. Not every pact will be upgraded to v4 at once (we can't enforce that), so we'll have a mix of: • v2 pacts with HTTP interactions • v3 pacts with HTTP interactions • v3 pacts with message interactions • v4 pacts with HTTP and/or message interactions The verifier gets in a serious mess when this happens. It starts sending the HTTP requests to the

/pact-messages

endpoint as if they're async requests, which then fails because obviously those are in a completely different format to what's expected. What am I supposed to do in that situation?

As in, you have a Pact file that has different versioned interactions in them? Or different consumers are on different versions of the pact spec?

The latter, yeah - some consumers have like v2 HTTP pacts and some have v4 pacts, but the verifier picks up the v2 pact and treats all the HTTP interactions like they're messaging interactions and hammers the provider with a bunch of invalid requests

ok that scenario makes sense to me, it sounds like it might be a bug then.

Yeah cool. I've started putting together a small example in C# as well, although having it in another language would be even better just to confirm it's not just the way I've implemented something

That's really onerous to put that requirements on everyone using message pacts though, so instead PactNet includes a little API which starts transparently to the user and implements the

/pact-messages

endpoint.

This sounds nice, I like your approach to the end user experience, it really showed in the migration from v3 -> v4 Your proposal sounds sensible 🙂

whereas from v4 we're allowing the same name for both HTTP and messaging interactions.

Yeah I actually haven't given that a whirl yet, but yeah that is a key feature

From v4, hitting the pact broker for

Orders API

might give you back v2 HTTP, v3 HTTP and v4 HTTP+Messaging, which is what causes the problem with the in-built messaging handler API

Yeah I assumed the pact verifier (whether via FFI or CLI) would just handle this, and therefore my recommendation would be to a user stuck on a v2 ruby-backed provider language but generating v3/v4 specs would be to use the verifier cli. Obviously that involves the user knowing more about the lifecycle and appropriate options, than it neatly wrapped up in the DSL Appreciate you putting together the examples 🙂

Nah, the verifier CLI would be broken in the same way

I'll let Ron mull over the implementation detail, as I have many yaks to shave, but sounds good and will be awesome to see this in pact-net

Say you have an API called

Orders API

with 2 endpoints: •

POST /api/orders

for creating orders •

GET /api/orders/{id}

for getting an order by ID and when you create an order, it also sends out a pubsub message to say that an order has been created. That's your provider API. Then you have 2 consumers: • Basket API - this calls

POST /api/orders

to create the order when a user clicks Buy. It is a v2 or v3 pact with only HTTP interactions • Fulfillment API - this listens to the pubsub topic for when orders are created, and calls the

GET /api/orders/{id}

endpoint to retrieve the new order details in order to trigger the actual shipping of the order. It's a v4 pact with both messaging and HTTP interactions inside When the Orders API hits the pact broker to perform a verification, it'll get both of those pacts back and start trying to verify them. In order to do that, the Orders API must have an endpoint called

/pact-messages

so that the verifier CLI/FFI can post a magic string to it and get a message body back. The problem is that the real Orders API doesn't have that endpoint, because that's a testing implementation detail. So, instead we create a little built-in API which has that endpoint so the user doesn't have to, and that's running on a different port to the main Orders API. This doesn't work though, either via the FFI or CLI, because you can only supply one URL. Either you give it the real Orders API URL, and then the messaging interactions fail because there's no

/pact-messages

endpoint, or you give it the messaging API URL, and then the regular HTTP interactions fail because it's just a little stub service for handling messaging stuff. So what you really need is to be able to provide two different URLs. One for the 'real' API, where all the HTTP interactions should be sent, and one URL for all the messaging interactions to be handled (which may be different to the HTTP URL, but doesn't have to be). In other languages you can probably monkey-patch the messaging endpoint onto the real API at test time from the test library itself, but you can't do that in quite a few languages. So either the library has to have a little built in API to handle them, or the user has to manually implement that endpoint (which is non-trivial). That situation would've never happened with v3 pacts, because you can't have a pacticipant called

Orders API

which has both HTTP and messaging interactions. They'd have to have different names and be in different pacts files, but from v4 that same name can now contain both, and that's what necessitates something that can handle the two types differently.

https://github.com/pact-foundation/pact-reference/commit/9b1b7965f0b97a8c7d11f2d8bb6bbeaa5a79e482#diff-afeb3e0e20ecfe56b3[…]f87602daaaa7c07de3dba859 now you mention this, it brings back memories of when I first trialled out plugins with Tien's PHP example, there was some oddities, I scattered a brain dump in some code comments, and sure I posted about it somewhere but can't find the issue or slack message about it, popping out for lunch shortly

Yeah so I think adding a transport is the way it would be done, but to do that I'm going to have to make a breaking API change in PactNet no matter what I think. When you create the verifier for the example above then you need to add both a HTTP transport and a messaging transport, but the API of PactNet currently only allows you to do one or the other, because in v3 pacts it wasn't allowed to do both (and I didn't know v4 allowed it at the time I wrote it like a year ago)

I could really do with a way of running a small built-in API on a different port to the main API and having all the

/pact-messages

calls sent over to that API instead. I can’t really mandate that users have to implement that endpoint themselves on their ‘normal’ API, nor can I write something which adds it on for them.

You’re right, this is part of the guide we need to write for maintainers (this is how it’s done in both JS and Go, and how i’ve recommended others do it. We discussed a callback approach, but trust me (and more so Ron), it makes the FFI much more low level and running an HTTP service is just much simpler to do).

I've added an RFC to the PactNet channel to detail why this is a breaking change. I've got it working locally now though with that breaking change

Nice! I had a quick pass now, but it’s late and I’ve already had a negroni. I’ll review with fresh eyes next week, and also compare against JS/Go for inspo

Just reading through all this, a maintainer guide would be a way to describe how to deal with this problem.

Good timing then 😉