It looks like once you used the plugin (

WithPlugin

), you can’t use

AsType

and

ConsumedBy

I can’t remember why I changed that now I’m sorry. There was possibly a good reason for it though 🙂

I’m guessing that the verifier doesn’t know it should be using the protobuf plugin to parse my provider message, what am I missing here?

Following up here, it looks like pact-go verifier is setting the provider proxy to return message as

application/json; charset=utf-8

, while pact expects it to be something like

application/protobuf; message=ProtoMessageExample

. I guess it means protobuf plugin won’t work with provider verification through message handler?

Also, even after I updated the line above to return the proper content type, pact doesn’t seems to be able to find the protobuf matcher:

2023-05-31T19:49:05.104537Z DEBUG ThreadId(01) verify_interaction{interaction="XXX"}: pact_matching: No content matcher defined for content type 'application/protobuf;message=SessionStatusResponse', using core matcher implementation

2023-05-31T19:49:05.104581Z DEBUG ThreadId(01) verify_interaction{interaction="async health information"}: pact_matching: No body matcher defined for content type 'application/protobuf;message=SessionStatusResponse', using plain text matcher

Digging deeper here, seems the async protobuf contract generated on the consumer side (through

AddAsynchronousMessage

) is missing plugin information. Unlike sync message, the async message doesn’t have

plugins

and raw proto desciptors under

metadata

. Also,

pactSpecification.version

is

3.0

for async contract, (instead of

4.0

for sync grpc contracts). That might be why the provider side can’t find the matcher from the plugin I guess.

Copy code

2023-05-31T19:49:05.104537Z DEBUG ThreadId(01) verify_interaction{interaction="XXX"}: pact_matching: No content matcher defined for content type 'application/protobuf;message=SessionStatusResponse', using core matcher implementation

hmm interesting. I suspect the plugin only registers

application/protobuf

and because of the additional field it’s mis matching (guess). What happens if you hard code

application/protobuf

as the content type? I wonder if that goes a little further (but then probably fails due to the missing qualifier).

Copy code

func(states []models.ProviderState) (message.Body, message.Metadata, error)

Hmm good point. I think we will need a variation on this that allows a

[]byte

to be returned here, and if a plugin is being used in an interaction, we use the different typed interface to signal that we require a byte array. We may also need to capture a content type here (or elsewhere) that is used to set the response mime type

Could you please raise an issue? Or - and this would be amazing ✨ - a PR that demonstrates how you get it to work? We can then pair through a solution to this problem

So the sync grpc version of generated contract looks like this to me:

{
  "metadata": {
    "pactRust": {
      "ffi": "0.4.1",
      "mockserver": "1.0.0",
      "models": "1.0.4"
    },
    "pactSpecification": {
      "version": "4.0"
    },
    "plugins": [
      {
        "name": "protobuf",
        "version": "0.3.0",
        "configuration": "..."
      }
    ]
  }
}

While the async generated contract has metadata like this:

"metadata": {
    "pactRust": {
      "ffi": "0.4.1",
      "models": "1.0.4"
    },
    "pactSpecification": {
      "version": "3.0.0"
    }
  }

In addition to spec version being 3.0.0, it also misses plugin information

On the consumer side I’m doing this to generate:

p.AddAsynchronousMessage().
GivenWithParameter(...).
ExpectsToReceive("...").
UsingPlugin(message.PluginConfig{
	Plugin:  "protobuf",
	Version: "0.3.0",
}).
WithContents("...", "application/protobuf").
ExecuteTest(...)

I'll aim to create an example next week to test it out myself

Btw part of the underlying issue is https://github.com/pact-foundation/pact-go/issues/265 I think

Thanks for the fix