message has been deleted

Hello, on your

v2.0.0-beta.14

branch, in consumer_v3_test.go you do:

ExecuteTest(t, test)

Where does the

test

come from?

It's possible there might be a bug with libpact_ffi install on mac M1. I dont have an M1 laptop but one of my developers experienced a similar issue reported in this thread here. Following the instructions here, the error reported on M1 was:

ld: can't open file, errno=13 file '/usr/local/lib/libpact_ffi.dylib' for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

A work around was to manually download the file relating to libpact_ffi-osx-aarch64-apple-darwin.dylib.gz and unzip into

/usr/local/lib/libpact_ffi.dylib

. These were steps noted in the output during install.

If I can get a reliable big report that would help. I use M1 exclusively now but on Rosetta mode (because there are just so many inconveniences otherwise)

👋🏽 not sure if there's some sort of mismatch issue for my build ci image, but i keep hitting an issue. see thread for details.

need help.. getting this while running the provider's test

Need Clarification on this: According to the Pact-Go instructions, we must have our provider API running in the background in order to perform provider verification. Additionally, I could see in the example that there is code to start the server as well as for the API handler. However, in one of the videos I watched about adding provider verification in go, the person didn't set up a mock server. I'm confused. Do we need to set up a mock server in the test.go file for provider verification, or could I just leave my backend server running in the background and pact will pull API details from the contract, make the request, and validate the response received against what we have in the contract since we are providing pactUrls in the pact.VerifyProvider or something else?

Does the Auto-generate matchers from struct tags documented here support injecting FromProviderState? I really like both of these features and opt to always use the Auto-generate, but in cases where I need to inject the provider state then I just go old school. Curious if this is supported and if not what would it take?

Hey all… curious if the v2 beta is close to stable/ready to go, and if people are using it without issues. We desperately need to get off of the Ruby tooling, but I can’t just swap one set of problems my team is having for a whole new set lol It doesn’t appear there’s been much activity the past couple months, but not sure if that’s because it’s stable or just contributor time constraints.

Using

pact-go v2.0.0-beta-14

on macOS. Two questions: 1) Is there something special I have to do to generate a pact file with multiple interactions for a given consumer? I have a consumer test with 3 cases that pass, but the pact file only seems to have the last interaction in the file 2) Is there something special I have to do to generate an interaction entry for a case that returns an error? I have a

404

test case, and the client under test responds to

404

by returning an error, which I check in my test (using the

testify/assert.Error

function). This test passes yet doesn’t generate an interaction in a pact file, even when the test is the only one executed. Any thoughts would be appreciated.

The v1.x.x docs for Golang says Pending Pacts and WIP Pact work only on PactFlow, is it still the case?

_NOTE_: This feature is currently only available on Pactflow

Hello 👋 The pact-go README mentioned that the support for async interaction is experimental. Why is it considered to be experimental and is there anything to read about it?

trying to follow the v4 example consumer for 2.x.x but can’t seem to get the matcher to work. it seems to want to do an exact match on the request no matter which matcher I select. this is in my WithRequest block:

Header("Authorization", matchers.Like("Bearer 111.222.333")).

and get this error running the consumer test:

2022/11/01 22:28:59 [INFO] pact validation failed, errors: 
                        Mismatch with header 'Authorization': Expected 'Bearer 111.222.333' to be equal to 'Bearer aaa.bbb.ccc'
:                       expected:        Bearer 111.222.333
                        actual:          Bearer aaa.bbb.ccc

here is the CLI:

~/go/bin/pact-go version
Pact Go CLI v2.0.0-beta.14

curious if this is a bug with

atLeastOneLike

. in my case i see body match fail for a fields response array mentioning index 0 and 2 failed to match but not index 1. so in reality at least one matched but the test still failed on the pact-go provider.

@Vlad Ledniov - here is where you can post your questions about Go integration.

good time of the day everybody ! I’m having some troubles launching Provider tests on golang, specifically, I’m getting a message that my Pact CLI is out of date:

2022/11/07 08:46:42 [INFO] checking pact-mock-service within range >= 3.5.0, < 4.0.0
2022/11/07 08:46:42 [ERROR] CLI tools are out of date, please upgrade before continuing

from my `go.mod`:

<http://github.com/pact-foundation/pact-go|github.com/pact-foundation/pact-go> v1.7.0

I’m seeing that 2.x.x version is still in beta, so want to try Pact with a stable version first before doing a transition to 2.x.x.

any chance VerifyPluginRequest will be getting support for StateHandlers and RequestFilter in the near future?

The GitHub user bethesque has signed out. Use the following command/s to recreate subscriptions /github subscribe pact-foundation/pact-go

latest update to pact-go 2.x.x seems to have issues retrieving pacts from the broker:

[2022-12-08T19:55:52.829Z] 2022-12-08T19:55:49.588545Z  INFO ThreadId(03) pact_verifier::pact_broker: Fetching path '/' from pact broker

[2022-12-08T19:55:52.829Z] 2022-12-08T19:55:49.611054Z  INFO ThreadId(03) pact_verifier::pact_broker: Fetching path '/pacts/provider/provider/for-verification' from pact broker

[2022-12-08T19:55:52.829Z] 2022-12-08T19:55:49.617698Z  WARN ThreadId(03) pact_verifier: Ignoring no pacts error - Could not load pacts from the pact broker

also for 2.x.x the provider state doesn’t seem to be getting put into the contract and i don’t see the state handlers getting called for gRPC - opened https://github.com/pact-foundation/pact-go/issues/253

and one more 2.x.x issue - the HTTP request filter seems to no longer be getting called: https://github.com/pact-foundation/pact-go/issues/254

Hi, we use ginkgo testing library to write unit tests! Would it be compatible with pact-go?

Hey Pact folks, and happy new year! I’ve followed the README for pact-go that talks about installing the standalone CLI tools, and adding their location to the PATH var. I’ve also cloned the

pact-workshop-go

repo, and if i run

make consumer

in there, everything runs okay, and the contract is generated, but I’ve tried doing the same thing for one of our own services, and whenever I try to run the consumer test there, I get an error saying that the CLI tools are out of date. Currently running on an M1 Mac. I’ve since tried using the

pactfoundation/pact-cli

docker image, and that seems to at least read the test, but just wondering if there’s anything obvious I’ve missed from the standalone CLI installation, or what the recommended setup would be for an M1 Mac.

looks like a regression in the gRPC provider verification with the 2.x.x branch: https://github.com/pact-foundation/pact-go/issues/260

Hello! I've got a question regarding request/response bodies matching. In my consumer test I describe interaction this way:

body := waveplanner.CreateWavePlanBody{
		Waves: []waveplanner.Wave{
			{
				CutoffTime: "04:00",
				FromTime:   "10:00",
				ToTime:     "15:59",
			},
			{
				CutoffTime: "12:00",
				FromTime:   "16:00",
				ToTime:     "20:59",
			},
			{
				CutoffTime: "16:00",
				FromTime:   "21:00",
				ToTime:     "09:59",
			},
		},
	}
	created := waveplanner.CreateWavePlanResponse{
		ID:    uuid.NewString(),
		MfcID: mfc,
		CreatedBy: "user-id",
		Waves: []waveplanner.WaveItem{
			{
				ID:         uuid.NewString(),
				CutoffTime: "04:00",
				FromTime:   "10:00",
				ToTime:     "15:59",
				Schedules:  []waveplanner.ScheduleItem{},
			},
			{
				ID:         uuid.NewString(),
				CutoffTime: "12:00",
				FromTime:   "16:00",
				ToTime:     "20:59",
				Schedules:  []waveplanner.ScheduleItem{},
			},
			{
				ID:         uuid.NewString(),
				CutoffTime: "16:00",
				FromTime:   "21:00",
				ToTime:     "09:59",
				Schedules:  []waveplanner.ScheduleItem{},
			},
		},
	}

mockProvider.
   AddInteraction().
   Given(fmt.Sprintf("retailer %s, mfc %s exists", retailer, mfc)).
   UponReceiving(fmt.Sprintf("a request to post wave plan for for retailer %s mfc %s", retailer, mfc)).
   WithRequest(http.MethodPost, fmt.Sprintf("/v1/retailers/%s/mfcs/%s/wavePlan", retailer, mfc), func(b *consumer.V4RequestBuilder) {
      b.
         Headers(matchers.HeadersMatcher{
            "X-Env-Type":   {matchers.Like("env")},
            "X-Token":      {matchers.Like("token")},
            "Content-Type": {matchers.S("application/json")},
         }).
         JSONBody(matchers.Like(body))
   }).
   WillRespondWith(http.StatusCreated, func(repsb *consumer.V4ResponseBuilder) {
      repsb.
         Headers(matchers.HeadersMatcher{
            "Content-Type": {matchers.S("application/json")},
         }).
         JSONBody(matchers.Like(created))
   })

running the test I get pact created, with these matching rules for _request/response bodies_:

"matchingRules": {
  "body": {
    "$": {
      "combine": "AND",
      "matchers": [
        {
          "match": "type"
        }
      ]
    }
  },

and of course the pact contains request /response body content. My question is: does this matchingRule means that on Provider verification stage the request/response body example will be used as a source of expected request format? Before this I was using the older pact version and used Body: dsl.Like(map[string]interface{}{}) way of describing expected response format, which produced exact matching rules per field.

Hi all, I am using the latest v2.x.x and I am noticing that the BeforeHooks are running before each of the state handler functions. But going through the code comments on the

verify_request.go

file they should run only once.

Am I missing something?

Hello. Can I have both versions of pact-go (v1 and v2) in my repo?

What do you say about an enhancement for pact-go 2.x.x Verifier as it relates to webhook re-verification? See thread here. It's probably easy to fall into this trap like I did. I have a webhook that triggers the provider verification during an event such as

Contract published that requires verification

. Utilizing the webhook template library here, I set the env var

PACT_URL

. However that doesnt actually seem to do much when using pact-go@2.x.x. and I am not sure how it works prior to using pact_ffi cli. I seem to recall a few

PACT_*

env vars being automatically read by the ruby cli tools. Could/should this env var also be automatically configured in pact-go verifier?

Hello! I continue to compare pact v1 and v2 and here is another diff: in v1 this part of interaction

WillRespondWith(
			dsl.Response{
				Status: http.StatusOK,
				Headers: dsl.MapMatcher{
					"Content-Type": dsl.String("application/json"),
				},
				Body: dsl.Like(map[string]interface{}{
					"code":      dsl.Term(code, uuidMatcher),
					"closed-at": dsl.Timestamp(),
				}),
			},
		)

generated this part of contract: