Support protobuf Any type

[stan-is-hate]

This is related to supporting raw bytes - #229
Any type is similar - it's just bytes plus a url describing the type.
https://github.com/protobuf-net/protobuf-net/blob/main/src/protobuf-net.Reflection/google/protobuf/any.proto
An ideal implementation would make this transparent to the user, for example, in your json your response might be:

"response": {
			"name": "notEmpty('Big Tree')",
			"location": {
				"latitude": "matching(number, 180)",
				"longitude": "matching(number, 200)"
			}
		}

but in your proto the type of response is defined as Any. The framework can then take those input bytes, find the corresponding proto with which to decode them, and use that decoded proto for matching.
The client shouldn't need to specify that the field is Any in the response really, unless I'm missing something

[rholshausen]

Happy to support this if the type of the Any refers to an existing message type in the proto files given to the test. This will be a small change to support. Most of the code examples I've seen seem to behave this way.

However, if the type if not defined in the proto files, that would be a problem. In the docs, it states that the type could be a URL where An HTTP GET on the URL must yield a [google.protobuf.Type][] value in binary format. It doesn't state what the binary format is (is it a descriptor or just the binary form of the google.protobuf.Type as a message?)

If any message can have a type that needs to be fetched, then the compiled descriptor for it must be added to the Pact file. If there are a lot of these types, that would make the Pact file get very large.

[rholshausen]

It won't be able to be totally transparent, it will require at least the type_url to work, otherwise there is no way to know which message type it is for.

Your example would have to be something like:

"response": {
  "type_url": "/examplepackage.ExampleMessage",
  "value": {
    "name": "notEmpty('Big Tree')",
    "location": {
      "latitude": "matching(number, 180)",
      "longitude": "matching(number, 200)"
  }
}

[stan-is-hate]

If any message can have a type that needs to be fetched, then the compiled descriptor for it must be added to the Pact file. If there are a lot of these types, that would make the Pact file get very large.

Personally I think it's fair to start with partial support and skip supporting remote URL types altogether. If there's demand, it can be added as a separate task. But up to you :)

it will require at least the type_url to work, otherwise there is no may to know which message type it is for.

But we receive type URL from the actual proto itself, during the test, can we just use that? Or do you want to compare that we've received the type we expected?

[rholshausen]

But we receive type URL from the actual proto itself, during the test

You are only looking at one side of the interaction.

The problem here is the dual nature of Pact tests.

Say you have this definition:
rpc calculate (MessageIn) returns (MessageOut) {}

In the consumer test, we send calculate(MessageIn) to the mock server, and it then creates a MessageOut to return back. If MessageOut contains an Any type, it needs to know the type to create the message correctly.

In contrast on the provider side, when we run the provider test, the verifier creates a MessageIn to send to the calculate service method of the provider. Again, if there is an Any type defined in MessageIn, we need to know the type to correctly create the message.

So depending on whether it is a consumer or provider context, we need to know how to construct the messages on the other side.

[austince]

Hey there, not very familiar with the pact setup, but would it be possible to have users specify the types / mappings to protos to reduce the complexity on the plugin to try to infer?

A non-esoteric use case for this would be mocking gRPC errors that include rich details: https://grpc.io/docs/guides/error/#richer-error-model
The gRPC error status proto itself uses the Any type for such details: https://github.com/googleapis/googleapis/blob/master/google/rpc/status.proto#L48

[stan-is-hate]

@rholshausen this make sense, I missed the verifier part - indeed, when verifier needs to send a message to the provider, it needs this data. Also including it in the contract is very explicit and obvious, so a better ux anyway.