Hi, when working with grpc plugin, I saw this behavior, so I want to discuss about it: At first I call

pactffi_verifier_set_provider_info

, it will create a default provider's transport

{transport: "http", port: None, part: "/", scheme: None}

. Then I call

pactffi_verifier_add_provider_transport

, it will create second provider's transport

{transport: "http", port: 8000, part: "/", scheme: "http"}

. Finally I call

pactffi_verifier_execute

, the result is

false

because it call provider on the wrong port (http://localhost, because it use the first transport, the provider is located at http://localhost:8000) Do you think it's an issue? If yes, I can think of some solutions for it: • Implement

pactffi_verifier_set_provider_info_v2

that didn't create default provider's transport https://github.com/pact-foundation/pact-reference/compare/master...tienvx:pact-reference:solution-1 • Don't create the default provider's transport at all https://github.com/pact-foundation/pact-reference/compare/master...tienvx:pact-reference:solution-2 • When calling

pactffi_verifier_set_provider_info

, set

scheme

to something that will be never used e.g.

scheme=invalid => transport=invalid

https://github.com/pact-foundation/pact-reference/compare/master...tienvx:pact-reference:solution-3 • Instead of appending new transport, try to find the existing transport with the same name and update port + part + scheme (no code, I don't think I know how to do it properly) Some notes: • This is why I think this issue is valid: I saw this attribute on provider info's protocol, port and path:

#[deprecated(note = "Use transports instead")]

• The example with 2 transport with the same name

http

may look strange to you. You may ask: so why don't call

pactffi_verifier_add_provider_transport

at all? Just put the port=8000 in the first call to

pactffi_verifier_set_provider_info

. The answer for this is the note above. • I need to test calling to

pactffi_verifier_add_provider_transport

because when working with the grpc plugin, I think calling

pactffi_verifier_add_provider_transport

is required so that the provider's verifier can work. The default transport

http

doesn't work with grpc

I think the actual fix should be that

pactffi_verifier_add_provider_transport

should update the existing entry if it has no port set, and not add the second one. The problem is that if we always update the entry, you can't have two different providers on different ports.

Another idea from me is to create new ffi function `pactffi_v`er`ifier_set_provider_tr`ans`ports` with json parameter for example