Expected repeated field 'x' to be empty but received 1 values

[stan-is-hate]

Here's the demo code: https://github.com/stan-is-hate/pact-go/pull/1/files
You can run make demo-error to check these scenarios.

I've discovered this error when I was testing a case where a provider returns a repeated string field (similar to tags) that consumer doesn't care about, so I didn't specify it in the consumer at all.

Turns out it's an issue even when the provider doesn't actually send back any value:

• If you omit a repeated field (tags) in the request (in TestSaveFeature), the test will fail with:

  Failed to match the request message - BodyMismatches({"$.tags": [BodyMismatch { path: "$.tags", expected: None, actual: 
  None, mismatch: "Expected repeated field 'tags' to be empty but received 1 values" }]})
  

• If you omit a repeated field (tags) in the expected response (in either test):
  • consumer test passes
  • but provider test fails with:

     Expected repeated field 'tags' to be empty but received 1 values
    

[rholshausen]

With the latest version of the plugin (0.3.12), changing the test to

grpcInteraction := `{
		"pact:proto": "` + path + `",
		"pact:proto-service": "RouteGuide/SaveFeature",
		"pact:content-type": "application/protobuf",
		"request": {
			"name": "notEmpty('A shed')",
			"location": {
				"latitude": "matching(number, 99)",
				"longitude": "matching(number, 99)"
			},
			"tags": "eachValue(matching(type, 'I am a tag'))"
		},
		"response": {
			"name": "notEmpty('A shed')",
			"location": {
				"latitude": "matching(number, 99)",
				"longitude": "matching(number, 99)"
			},
			"tags": "notEmpty('I am a tag')"
		}
	}`

then both consumer and provider pass.

[rholshausen]

It might be the handling of default values that is causing the error when you leave the tags out of the request

[github-actions]

👋 Hi! The 'smartbear-supported' label has just been added to this issue, which will create an internal tracking ticket in PactFlow's Jira (PACT-1788). 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.

[rholshausen]

0.3.13 has been released

[stan-is-hate]

I've done a basic test inside pact-go and it seems to have been fixed, thanks @rholshausen !
I'll report here if there are any edge cases that still don't work, but so far so good!

[stan-is-hate]

I'm still seeing it in one of my projects though, will investigate if it's related to a specific proto layout, something inside our codebase or something else.

[stan-is-hate]

Ah, so it seems to be fixed for the case of default values, but there's still the case of when the consumer doesn't care about whether the field is present in the response or not, but the provider returns some value.
In the example here:
stan-is-hate/pact-go#1
in the GetFeatureTest the consumer omits both description and tags fields in the response, while the provider returns values for both of these fields (configured at the bottom of server.go). If you make the provider return only the description it works ok, but if it returns tags it becomes not ok.
An easy solution would be to include "tags": "eachValue(matching(type, ''))" in the response, so it's not a huge blocker, but it would be better to not specify it at all.
Thanks!