github-actions[bot]
commented
1 year ago 👋 Hi! The 'smartbear-supported' label has just been added to this issue, which will create an internal tracking ticket in PactFlow's Jira (PACT-1140). We will use this to prioritise and assign a team member to this task. All activity will be public on this ticket. For now, sit tight and we'll update this ticket once we have more information on the next steps.
See our documentation for more information.
(Via @adamrodger )
The
pact_verifier_set_provider_infoFFI call (here ) includes adding a default transport when setting up the verifier, but this makes integrating with the FFI awkward for libraries.Since Pact Spec v4, a pact file can now contain both HTTP and message interactions, and this is implemented by adding a transport for both HTTP and messaging via
pact_verifier_add_provider_transport(here).The problem is that when the user is setting up a verifier, they want to specify 3 things:
The FFI forces them to treat those as two things instead of three though, because specifying the provider name forces you to supply a transport. This creates an awkward API because there are three possible combinations for setting up a verifier:
Plus in future there may also be plugin-based transports, which creates a combinatorial explosion.
You can kinda deal with this in library code by either storing the name up and only adding it once the user has either specified HTTP or messaging, or you can check if you've already added a transport when you add subsequent ones and call different FFI methods. That's what PactNet does here
That's an awkward thing that every library developer has to implement though, and they may implement them differently. Instead I'd prefer if the FFI allowed you to specify the provider info without having to specify a transport, and then initialising the verifier and adding the transports are separated and easy to integrate with.