has joined #pact-rust

/github subscribe pact-foundation/pact-reference releases

/github unsubscribe pact-foundation/pact-reference deployments public commits

has joined #pact-rust

has joined #pact-rust

has joined #pact-rust

has joined #pact-rust

Hey, posting here because the pact-stub is written in rust and not sure if it applies to any of the other channels. I raised an issue on the pact-stub-server issues list on github a few weeks back. Not sure if anyone saw it or had any feedback? https://github.com/pact-foundation/pact-stub-server/issues

That project is for building the docker image, so that is why nobody has looked at it. I'll create issue against the actual project and link it

Oh, thanks for pointing that out. Sorry it was put in the wrong place :disappointed:

No, not your fault. It's ours for having 2 projects in different places :wink:

has joined #pact-rust

has joined #pact-rust

has joined #pact-rust

has joined #pact-rust

has joined #pact-rust

:wave:

I'll add my previous notes a bit later as I had spiked both JS and Go using the rust lib. The main barrier from memory was that it previously didn't serialise the pact, so this would require the language binding to do that work. Also there are a bunch of new features in the languages we'd need to assess against what's currently been built

It also contains model classes that can serialise/de-serialise to the JSON format, so those could be re-used

But language implementations should use a proper set of models to represent a pact

Indeed

Hi, I have started work on converting pact-reference to tokio/async (hyper 0.12). This is quite time consuming, but fun to work with. There are a couple of architectural implications as a result, that can be discussed here or elsewhere. It?s far from done, but if anyone?s interested you can find the in-progress branch at https://github.com/audunhalland/pact-reference/tree/hyper_upgrade

thanks for jumping in and giving it a crack

has joined #pact-rust

has joined #pact-rust

Question: is it possible to define a regex matcher for a plain text body of a multiformdata request? For details see: https://stackoverflow.com/questions/5737262 9/how-to-define-pact-specification-matching-rule-for-single-string-body. Help would be much appreciated. We got stuck with this. Thanks!

Prob better to implement support for multi-part bodies. I answered as such in SO.

Does this mean that regex matching on a full text body is currently not possible? The regex is not too complicated in this case as we now how the consumer is generating it.

I agree that implementing multi-part body support would be better, but I am afraid we don't have time for that right now.

Ow, by the way, we use the library of the rust implementation from C++. So I think we can only use pact.json files as input.

I just checked the implementation, and it is not applying matchers to the text bodies. Can you raise a issue at the Github project for this?

Thanks for checking! I created the issue as requested.

@c.metz if you want to design a better interface to support calling from C++, we can implement that.

No new release for pact verifier?

Sorry, I ran out of time. I was trying to remove all the old versions of hyper first

I'll see about getting it out as is

No worries :slightly_smiling_face: I just wondered if there were any remaining blockers left or you just forgot.

I can wait

Hi again, as I mentioned earlier this year my goal is to use the rust verifier with a node.js provider. I wonder how to approach that. Should I download `pact_verfifier_cli` in that project and be done with it, or do you instead want to migrate of `pact-node` itself to use `pact-reference`? If you want to do that, I am also willing to help. Of course the benefit of that is that JS consumer tests will also use pact-reference.

:wave:

See https://github.com/pact-foundation/pact-js/tree/feat/v3.0.0

This process has started, but we really need to do a bit of a planning session on this. My thoughts are to put together an RFC-style document that we can share. That?s on me as the core maintainer (of JS)

TL;DR to get moving quickly, using the verifier CLI. If you want to be on the inside track, it?s going to be a few months of work, but would certainly appreciate helping hand

Sorry the late reply. I am currently too busy to work on that but will consider for the future. Thanks for the help!

I did it :slightly_smiling_face: now building our CI pipeline using `pact_verifier_cli`!

awesome @audun.halland!

Publishing the results to the broker is doable without Rust, but a PR would be nice if it doesn?t exist eh @uglyog?

Yeah, PR's are awesome. @audun.halland has already done so much! I have some time this weekend, anyway. Can't believe I missed this.

Nice :smiley:

has joined #pact-rust

`json_pattern!` is completely awesome. I didn?t expect to be able to write consumer tests in rust that easily.

just a side note: not that I?m really there yet, but how am I supposed to publish generated pacts from a Rust project?

ooh, you come up with the best questions :smile:

Publishing is just a PUT request to the pact broker. But I can write a CLI for you, or you can use the standard Pact CLI

Or just script it with Bash

Or Powershell, if that is your thing

ok, curl seems like the way then, thanks

I might write a CLI anyway, because there is complexity with tagging and versions

@audun.halland You can use the pact-cli: https://hub.docker.com/r/pactfoundation/pact-cli

Many thanks, will try that eventually. Obviously it will take some time to develop this Rust app

has joined #pact-rust

It appears that the latest version has reintroduced regex errors, a bug that was previously fixed by using the `onig` lib

Btw, did you have any progress on pact-js v3?

Hmm, that?s not good. It should still be using the onig crate. Can you check what crates where compiled?

The consumer side is working, for the provider verification side I was waiting for a PR to be merged in Neon which is the library I?m using that provides JS to Rust bindings. Looks like it has been merged now, so just need to wait for the next release of Neon

Yes, I haven?t checked it in detail yet

Some colleagues saw some regex related errors after upgrading verifier-cli to latest

I?ll investigate a bit

We can?t reproduce it now, so just forget this. What I?m misssing though is a release of linux `pact_verifier_cli` 0.7.x for my CI builds

has joined #pact-rust

I didn?t release the cli binaries because of the issue I had and wanted to test them some more. Could you not build them yourself?

I?ll have some more time this weekend

There?s no rush, there should be no functional changes to the verifier after all, I just wondered if you had forgotten

has joined #pact-rust

Hi! I saw there was a compilation issue and came up with this fix. Happy to answer questions here or on GitHub. Not sure the protocol. This is my first contribution to Pact.

It occurs to me it may be better to add a private empty field so the type can't be constructed (private fields, no constructor) which would better avoid possible accidental instantiation in the future. I'll try that change.

I've pushed that change, and confirmed that the type is now unconstructable, so it can _only_ be used for type-level programming.

Looks like some broken tests had been hidden by the prior compilation issue. Just pushed a third commit which fixes those tests.

@abrinker we've merged your PR, and there looks like a flakey test failing which we have ignored for now

Is it a test that's unstable on windows?

The one that failed for me was OSX but then also failed on Linux. It's needs some uplift to be a good test anyway so we'll figure that out

Thanks @uglyog!

> chore: remove unused import from provider_client (Matt Fellows)

Look @matt.fellows helped with a Rust component :smile:

I believe there are some commits in the JS repo now with Rust code :wink:

OK, so let?s swap - today you do marketing website and i?ll do Rust - sound good?

cool, you commited some new stuff on v3.0.0. I can?t wait :grimacing:

I'm hoping to get the first beta out today

Per the discussion here in #pact-c-plus-plus, https://pact-foundation.slack.com/archives/CPGH2TLLX/p1584386254001600, our team is planning on making a few basic enhancements to pact-reference: ? Add a new MessagePacts struct (variant of existing `pact_matching::models::Pact`) ? Add FFI interfaces to read/verify Pacts for `match_message`, `Message`, and the new `MessagePact` to allow these to be called from C/C++ We were then planning to create a thin C++ program to use those methods to orchestrate Pact provider verification. Would this be duplicative or contrary to any of the Pact team?s current plans for C++/Rust? If so, please let us know and we can change direction.

No, the initial kickoff for the C++ integration has not happened yet, so I think you can go ahead

@uglyog Aggeees ago I had ago at implementing the rust native lib into the swift code base (2 years ago). It was probably 80% functionally complete (and another contributor has taken that further and finished the remaining matcher, but there are still lots of rough edges). @marko.justinek is keen to give it another crack, but I?m not sure if things have changed much since that time and it may be an easier endeavor now? I see you guys have been working on this for pact-js.

has joined #pact-rust

Rust support from other languages has changed, but the implementation you worked with is still much the same

oh hello

I had a bit of chat with Marko last night

For pact-js, we are using a Rust<->JS binding library

Two of the key files I put together back in the Go days: ? https://github.com/pact-foundation/pact-go/blob/feature/native/dsl/matcher.go - generating a v2 compatible spec (no generators) ? The native package: https://github.com/pact-foundation/pact-go/tree/feature/native/dsl/native (links to the Rust c interface)

ahh, right, where does that live? Or is it part of the pact-js branch?

That spike worked

It should be much easier on the consumer side, because the mock server and matching all works, and you don?t need to do the provider side

pact-js V3.0.0 branch

:ok_hand:

yeah, this should be enough to give it a crack

The gaps if you were coming from the Ruby implementation (from memory, need validation): 1. You need to generate the pact _before_ running the pact tests (they aren?t generated like in Ruby) 2. Pretty printing of the error diffs is something you need to do

Yeah, I have a spike implementation of all that already.

nice

There is a lot of tooling work that needs to go into it. e.g. how to specify the pact output location, get debug logs to users, and there was some weird linking issues with iOS (maybe that has been resolved).

its complicated by having to run stuff in a simulator

mmmm

specific to iOS

If I understand correctly, you currently run the Pact server _external_ to the simulator - I?m sure you couldn?t do that within, right?

correct

with rust, can run it in the simulator, which is what we are hoping for. Otherwise we have to rely on external ways of starting and stopping the server

yeah. Much nicer experience I imagine

it makes the setup and documentation a PITA. plus we cannot do things like pact broker integration.

Running the mock server in the simulator feels wrong to me, because the actual server won't be running on the device

we can run without spinning up the iOS (iPhone) simulator but that would require us to go into command line and use `xcodebuild` or `xctool` but that?s normally only used in CI, not when writing unit tests. When working in Xcode and hitting ?run tests? for iOS it automagically spins up the simulator.

the main idea of me giving it another crack at it is to avoid the pain of setting up the Ruby dependency, setting up the IDE environment, dealing with builds going belly up due to dependencies, having to run multiple pact-mock-services if I have multiple providers, etc.

also, swift from has made huge leaps from when Andy started his framework

anyway, I think I have a decent idea now how to proceed and Matt?s go example will be a good reference too

so, stay tuned and I?ll be throwing some random (mostly stupid) questions your way? maybe.

true, but they aren?t really meant to be e2e tests are they? I think tooling / developer ease of use might trump in this case??

I saw the pain that running it outside of the simulator introduces with Marko a few weeks ago. There is just so little visibility and way to link them together nicely, I can see all kinds of confusion ensuing.

So whilst I agree that running within the simulator isn?t ideal, it still makes a network request and will solve a lot of the ergonomics

LFS specific requirements and environment opened up a lot of questions and opened some more cracks that could be addressed with a new approach

especially, having to spin up 9 mock services if there are 9 providers :facepalm:

or, if the CI build gets cancelled (due to another push), the subsequent build fails because mock services are already running and the new build can?t spin them up again? can get frustrating to work with

yeah. The Rust experience is much nicer. It will also perform a lot better.

as long as an actual HTTP request is still being made

/github subscribe list

/github subscribe list features

has joined #pact-rust

:clap:

What you clapping for?

binary payload matching, seems pretty cool

has joined #pact-rust

The stub server seems to want an exact body match on requests made to it but we want to be flexible on one field in particular in a JSON POST body and it doesn't seem to support falling back to the matchers specified in the pact

Can you raise an issue and be specific about the behavior you want?

So I realized our use case was a little... off. I resolved it by using an echo server for this use case. I may still write an issue describing the issue, especially if we decide we want to move back to the stub server for this or something else in the future.

has joined #pact-rust

Hi :wave: What is the `description` parameter defined on `new_interaction` in the FFI library? (https://docs.rs/pact_mock_server_ffi/0.0.7/pact_mock_server_ffi/fn.new_interaction.html) Is it the same as what?s called/used to be called(?) the ?state? string?

It would be the scenario name I'd imagine

I.e. the `UponReceiving` from https://github.com/pact-foundation/pact-net

Hmmm :face_with_monocle: There is an `upon_receiving` function defined in the Rust library too, and it turns out that the `given` function takes the state string.

I'll try and look at the rust interfafe later today

`new_interaction` creates a new interaction, which requires the description. `upon_receiving` just sets the description for the interaction. You don't need to use it unless you are changing the description.

I think there was a flow in the C++ DSL where we needed the interaction handle in the constructor, but we did not have the description yet, so `new_interaction` was called with a default description and then `upon_receiving` was used later to update it.

Is there an example on how to implement provider verification in a Rust project? I know that I can just go by the http://docs.rs but I'm a much faster learner when I just see it applied. Thanks in advance!

Still super happy that Pact exists :D

There is a CLI verifier you can use: https://github.com/pact-foundation/pact-reference/releases/tag/pact_verifier_cli-v0.7.0 docs https://github.com/pact-foundation/pact-reference/tree/master/rust/pact_verifier_cli

has joined #pact-rust

Hi there! My name is HeyTaco!, and you can use me to give people tacos to show your appreciation. My tacos will spread joy through Slack!

@uglyog how does one release the latest Rust stuff? I notice the changes pulled in a while back for the tls certificates aren?t released for https://github.com/pact-foundation/pact-reference/tree/master/rust/pact_mock_server_ffi

I can see the groovy script there, is that manually run or via some other automation?

It's manually run

I'm happy to learn. Does it need any specific dependencies to kick it off?

(sorry not in front of computer now but if it's just that it needs groovy I can probably work it out)

I assume needs GitHub creds at the least

It needs push access to Github, and a key for http://crates.io

I'm busy adding message pact support, so will be doing a release soon

I saw that PR but couldn't see how immediately it could be used

It can't

@uglyog Made my day to see new updates to the Rust libraries. Here's a taco :taco: :tada:

How do I authenticate the `pact_verifier_cli` to my self-hosted Pact broker?

I think I found it. Nvm

has joined #pact-rust

@matt.fellows can you create Github releases for the two modules? They are not automatically created.

ah!

sure

How do you normally do that?

I just do it from Github

Actually, I should release a new verifier CLI too. Will do that now

that all look OK to you? (I removed the commit sha?s in the release notes as per the others too)

It probably needs to be automated, but I sometimes like to add a blurb at the top

How do you upload the CLI artifacts? Do first run the `./release.groovy` and then run the docker scripts to generate OS specific artifacts?

A GH action builds the artifacts. The ZIP file will need to be downloaded, unpacked, and then attached to the release

I got a GH action publishing the artifacts somewhere else (Pact-JS I think). We can reuse that to do it automatically

cool

chuck that on the #TODO :stuck_out_tongue:

so I was waiting for some build to finish for the artifacts to publish, but then realised that I need to first create a GH release to get the artifacts to publish to the release :laughing:

has joined #pact-rust

has joined #pact-rust

Hey guys. I?m working on some pact verification for a rust/tokio server. Setting up https://docs.rs/pact_verifier/0.9.5/pact_verifier/fn.verify_provider.html, my state change server and actual provider server with tokio, I expect this to just work. But.. there?s a commit (https://github.com/pact-foundation/pact-reference/commit/126b4635613820bcdc827f605a63b72fcc98d7dd) that changes `verify_provider` to block internally, causing my state change server to never respond, because the tokio runtime is already busy blocking.. Also I cannot understand from the commit msg why this was changed to block. Some help?

Just looking into that commit. I think it is an issue with Neon not providing any mechanism to deal with a promise yet

A fix could be to change the public verifier API to be blocking.

I'm working on Pact-JS today, so I'll try sort this out for you. The blocking requirement should be implemented in Pact-JS, not the downstream Rust crate.

Not sure. There?s not really any need for the public Rust API to be async, because that would tie every user to use the tokio runtime.

using threads in tests would be more ?universal? perhaps.

Good point about the public API. I'm going to add a blocking version so we can have both.

Looking at that blocking code, I think a join3 would actually work there. Let me play around with that.

Nice, thanks. So you also want to keep the async tokio version (which of course cannot be allowed to block)?

Yes, because I think it is used in Pact-JS. I'll confirm that.

I've removed the block_on calls and released updated version

thanks :pray:

Though, I think I want to wait for full tokio 1 support, to avoid temporary duplicated dependencies. `reqwest 0.11` should be right around the corner.

https://www.reddit.com/r/rust/comments/kr5jmp/reqwest_011_released_updated_for_tokio_10/ :grimacing:

Hi, @uglyog, would you care to make a new `pact_consumer` release as well? The current version still has e.g. `regex 0.1`

has joined #pact-rust

Hi @audun.halland @uglyog, can I ask some stupid question? How can I run standalone pact mock server ( https://docs.rs/crate/pact_mock_server_cli/0.7.3) ? I means where can I get the command or source code something like this https://github.com/pact-foundation/pact-ruby-standalone/releases

I try to find this for the whole day please forgive me ;(

Maybe here? https://github.com/pact-foundation/pact-reference/releases/tag/pact_mock_server_cli-v0.7.3

If you mean an actual executable

There is also a docker image for it

Hi team!, I've a question for pact-stub-server. Is it can respond data that depends on request? sth like this ```{ "request": { "firstName": "Tony", "lastName": "Strange" }, "response": { "userFirstName": $request.firstName, "userLastName": $request.lastName } }```

not at the moment, but this is a great idea. We?ve talked about extending the mock into this sort of thing before - e.g. predicates/expressions etc.

if you?re keen, a feature request at https://pact.canny.io/ (and/or a PR would be great :stuck_out_tongue: )

I think you need to add more category for stub-server

Btw, I've created new post already https://pact.canny.io/feature-requests/p/allow-pact-stub-server-to-respond-data-that-depends-on-request. Thanks

has joined #pact-rust

Hi I was wondering if someone could help me install the Rust Mock Server CLI? Struggling to work out how to do this and I'm not sure if I've missed something obvious

You can use the executable from https://github.com/pact-foundation/pact-reference/releases/tag/pact_mock_server_cli-v0.7.3

Just unzip it after downloading

Out of interest, what do you want to do with the Mock Server CLI?

(vs the stub server: https://github.com/pact-foundation/pact-stub-server)

My aim was to send an interaction from a dart test to the mock server for verification

Will give the above a try and let you know if I have any questions. Thank you!

Hi team! I found this problem when I try to run pact-stub-server with -b <broker-url> Can someone help me? T_T

Actually, I tried to run on another laptop and it's work but cannot fetch all contract file, it keep stuck in the same contract. Not sure what the problem is xD

AH it's fixed now, just restart

I got this instead

@vuttithatkrongyot can you raise a Github issue for that?

Sorry, I just found that it broke because of my contract. Now it's works correctly. Thanks

Hi, I?m developing pacts in Rust again! `pact-consumer` supports matching patterns with macros like `each_like`, `json_pattern`, `like`, and `term`. Is there a way to make a date matcher, that?s not described in the documentation?

I realize I can use `term!(pattern, example)`, but knowing there is native support for dates deeper somewhere in the Rust libs, I?m thinking it shouldn?t be too difficult to publicly export some more patterns in pact-consumer..?

The consumer DSL needs to be updated for all of the newer features, like matching values ignoring the keys, etc.

I think it is currently on-par with the Ruby version

@uglyog any chance you could please grant me access to publish the FFI variants (and other packages)?

I've added you to all the things

Would some of these functions help? (I don't read rust very well) https://github.com/pact-foundation/pact-js/blob/feat/v3.0.0/native/src/lib.rs

It's more the Rust consumer DSL needs to be updated for the new features

Yes, I was wondering if there was anything there that could be cribbed from

Oh, yeah, definitely!

has joined #pact-rust

GitHub app is successfully upgraded in your workspace :tada: To receive notifications in your private channels, you need to invite the GitHub app `/invite @GitHub`

Hi! I just opened a PR against the `pact-reference` repo that I'm happy to discuss here or on the PR itself. It's fairly large, and adds a new crate called `pact_matching_ffi`, exposing `pact_matching` and (with recent changes) `pact_models` over FFI, for use by other languages.

Awesome, I'll have a look today. I'll be slowly moving the models out of the matching crate into the models one. I hope that doesn't impact what you are doing

Thanks, it?s so nice to see such well thought out, documented and presented PRs - a work of art!

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_matching-v0.8.14_ published by uglyog

I assume we should setup the CI to build the shared libs and header for this crate and attach them to the github releases

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/pact_verifier-v0.10.5_ published by uglyog

yep. We should also publish checksums, should be fairly easy

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/pact_verifier-v0.10.6_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/pact_verifier_ffi-v0.0.3_ published by uglyog

has joined #pact-rust

Glad y'all like it! We knew going in that this would be a big PR up front so we wanted it to be as easy to understand as possible.

has joined #pact-rust

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_models-v0.0.1_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_matching-v0.9.0_ published by uglyog

Hi, I'm trying to use DSL functions with pact-rust pact_mock_server_ffi. And I have the error above :point_up:

This is the code https://github.com/tienvx/pact-reference/blob/add-php/php/src/consumer-1/matches.php#L14 How can I see the log of this error, and how can I fix it?

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_models-v0.0.2_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_matching-v0.9.1_ published by uglyog

You can enable log output with the `init` function. By default it will setup logging based on the `LOG_LEVEL` environment variable. So set `LOG_LEVEL=debug` and then call `init` in your PHP script.

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_matching_ffi-v0.0.1_ published by uglyog

Will try

I tried, but it does not print any log output. I think this problem: > Segmentation fault (core dumped) Come from this line: > if let Some(description) = convert_cstr("description", description) {

has joined #pact-rust

has joined #pact-rust

Hi Folks, just wondering if anyone knew of an example of using message based pacts? I saw that the `pact_consumer` crate doesn't support messages yet, but the functionality does seem to be in `pact_matching`. I'm currently working through it, but an example would be great if it exists, thanks!

@uglyog ok if I release the latest FFIs and any dependencies?

I haven't seen an example yet, I'll see if I can set one up for you.

I need to release a whole bunch of crates today

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_models-v0.0.3_ published by uglyog

cool that?d be ace

Someone is also asking about a consumer message test in Rust. You up for that?

As in you want me to add? I can try

No, no need unless you really want to

I'll probably try sort it out today

I probably won't get time today so go for it. I've been dabbling about but am offline now basically

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_matching-v0.9.2_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_matching_ffi-v0.0.2_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_matching_ffi-v0.0.3_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_mock_server-v0.7.17_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_mock_server_ffi-v0.0.17_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/pact_mock_server_cli-v0.7.4_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/pact_verifier-v0.10.7_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/pact_verifier_ffi-v0.0.4_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/pact_verifier_cli-v0.8.5_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/pact_consumer-v0.7.6_ published by uglyog

That'd be great thanks! If not, I'll probably figure it out over the week and will write something up on it also.

Dang, we should probably setup musl builds for rust: https://github.com/pact-foundation/pact-js/runs/2708388385?check_suite_focus=true#step:3:835

has joined #pact-rust

Hi folks, I'm working on a refactor and I found these two functions, `MatchingContext::matchers_for_exact_path` in `pact_matching/src/lib.rs` (https://github.com/pact-foundation/pact-reference/blob/4038e6118a162961bf55b85ea829c0e627f3c60b/rust/pact_matching/src/lib.rs#L433) and `MatchingRules::resolve_wildcard_matchers` in `pact_matching/src/models/matchingrules.rs` (https://github.com/pact-foundation/pact-reference/blob/4038e6118a162961bf55b85ea829c0e627f3c60b/rust/pact_matching/src/models/matchingrules.rs#L1376). Neither of them are directly tested, but I did find tests in `pact_matching/src/tests.rs`(but I can't find them now --- maybe they were removed recently?) and in `pact_matching/src/models/matchingrules.rs` that cover only the case where the category is "body". My questions right now: ? Are these functions actually used? I see deprecation warnings on some of the uses, but I'm not sure. ? If they are meant to stay, what exactly are they doing? It's not clear to me how the different cases are meant to work, and it concerns me that two of the cases appear to be uncovered by tests. I'm specifically curious about what check/operation is being done conceptually with the JSONPath here, since my intended refactor PR is all about the JSONPaths.

Yes, those are used. There should be tests, if not, please raise an issue for that. `matchers_for_exact_path` is used by matchers like `ArrayContains` because these matchers must not cascade down to child elements. `resolve_wildcard_matchers` is there to support deprecated matching logic which have been replaced with the `values` matching rule.

Eventually it will be removed.

There are some tests in `pact_matching/src/tests.rs`

Alright, thanks for the info. I didn't catch the usage by ArrayContains, but had seen the deprecation warning you mention. I'm hoping to understand the concept of the "exact path" here. The code in the Body branch seems to be checking that the path weight is nonzero (which I understand to mean "matches in any capacity whatsoever") and that the lengths are equal. Is this the same as matching as much as possible? And either way, do you think this is a good candidate for refactoring into a generic operation/check on JSONPaths? I ask since I'm already refactoring. I'm just not sure what the documentation on that new function would say.

Ah, bit of history. The first matchers were designed to cascade, so that `eachLike` could be applied to all attributes of the object. That way the first matcher found by going up the tree was used.

There was a need for someone to match the values of an object, regardless of the keys (where it is treated like a map structure). As there was no mechanism to do this, a wild card type matcher was added (ending in a `*`), and if this was seen then the keys were ignored. But this caused other problems, because of the implicit nature of how the rules are setup.

So a "match only values" matching rule was added. But when matching a map, this rule must not cascade (i.e. when matching an object, don't also ignore the keys when matching child objects).

so, `resolve_wildcard_matchers` is deprecated because it has problems, but needs to be there to support older pacts (I'm of two minds on this). `matchers_for_exact_path` is used where matching rules must not cascade.

Alright, thanks so much for the detailed background. I'm going to have to reread this carefully to wrap my head around it. On further rereading of the path weight and equal length check in `matchers_for_exact_path` and thinking about how calc_path_weight works, I think that the path weight would be zero if any token did not match, since the token weights are multiplied together in the accumulation (with `fold`). A nonzero result weight means that the path matched at least up to the length of the JSONPath. Thus you only need to check that the actual path is not longer than the JSONPath (which would mean there were un-checked tokens), to confirm that the JSONPath exactly matches the path under test. And for the purposes of this check, the particular path weight is irrelevant as long as it's not zero. Am I correctly understanding this?

Yes, that sounds correct. If I recall, I think it checks that the weighting is > 0 and that the matched path elements is equal to the path length.

@matt.fellows Your changes to `pact_verifier_cli` have resulted in `pact_verifier_cli -v` printing out the version from the FFI crate. I have fixed this in https://github.com/pact-foundation/pact-reference/commit/e8d6d84414e266d0557d6aee4f7260b70a2caf18 but it may have broken Pact-Go

ah crap, sorry

looking at your change, it should be fine - pact go doesn?t use the CLI

Unless I?m missing something?

No, just the function signature changed

Huh! Typical! ```$ git bisect bad 62a653cfe52f6283af38f6a8620192d2e8ea27ef is the first bad commit commit 62a653cfe52f6283af38f6a8620192d2e8ea27ef Author: Matt Fellows <matt.fellows@onegeek.com.au> Date: Thu May 27 23:40:27 2021 +1000 chore: remove unused imports rust/pact_mock_server_cli/src/server.rs | 2 +- rust/pact_verifier/src/tests.rs | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)```

did it break stuff?

CLI Mock server just starts up and then exits

huh

so much for the rust compiler picking up useful bugs!

Might be because of this: ```- let (shutdown_tx, shutdown_rx) = channel::<()>(); + let (_, shutdown_rx) = channel::<()>();```

It's not waiting, because it is all async

I mustn?t understansd what `_` does. Does it not bind a variable at all, or just tell the compiler ?I know I don?t use it, but please stop complaining?

Yeah, I think it doesn't create a local variable, which probably causes the destructor to be invoked, and the server thread then exits

So `_shutdown_tx` it is?

The server future waits on that channel, so if it is de-allocated it will exit. Makes sense.

indeed

but also, holy shit. That has got to be up there with the most innocuous change I?ve made that has had a catastrophic impact on an app.

I was dreading the git bisect ending at "chore: update to Tokio xx Hyper yy and make it async"

It was a relief when I saw the bad commit

yeah, my commit is a fair bit easier to fix I would say

Probably we should add a really simple smoke check in the pipelines - e.g. see if the CLIs run

Nobody is complaining, so they probably aren't using that CLI or they haven't done a docker pull etc.

Yeah I?m surprised I hadn?t seen any issues :grimacing:

has joined #pact-rust

hey! I guess I was the first one to bump into that last Wednesday then :smile:

Hello again folks, following up about my upcoming Pull Request related to refactoring JSON Paths. The situation is that my team would like to implement a feature whereby JSON Paths may include XML prefixes to disambiguate XML namespaces (a future PR). I concluded that JSON Paths would need to be changed (this PR) in such a way that they are parsed immediately upon parsing of the containing Pact structure (Request, Response, or Message), instead of being parsed lazily. That would allow XML prefixes contained in the JSON Path tokens to be resolved before matching occurs. (I considered a design where XML namespace+prefix information was passed through into matching instead, but abandoned it because it would require too many changes, and would spill out of XML-specific matching code) One behavior change included in this refactor is that parsing errors for the JSON Path expressions will occur at a different time, namely on construction/parsing of those Pact structures rather than during matching. The current codebase actually ignores parse errors, converting them into log warnings and returning a path weight of zero when matched against any path. *I'm hoping to get feedback specifically about this change to error handling*, but any other feedback is of course welcome! The work in progress is here: https://github.com/mitre/pact-reference/commit/c525f264afa48fffe4315400551a36e9ac7ec96e The diff is very large, but the gist is that I'm moving `calc_path_weight` and `matches_token` into `http://path_exp.rs` and encapsulating JSON Path operations into a new type, `JSONPath`. Other disclaimers: ? This work is based on an old version of `pact-reference/master`, but I think the diff is still representative. ? I think I was incorrect in my comment in the commit message about the potential issue where HTTP headers and query strings are plain strings rather than real JSON Paths. I later realized that all strings do eventually get parsed as if they are JSON Paths. Please let me know if you can confirm this one way or the other. Thanks very much!

I can review it when I get a chance. If the diff is large, is there a way we can split it up? I have been moving the models out of the matching crate into a separate models one, so that may affect your branch, especially if it has been long running.

I was trying to keep it small, but the changes needed just to get it to compile kept escalating and spreading across the codebase. Turns out a lot of stuff works directly with JSON Paths :) So I'm lost on how to split it into any logical pieces, but I'm all ears. I linked directly to the diff in case you were curious, but mostly I wanted (at least for starters) to get a basic sense of whether this change fits your design and plans. In particular the error handling bit, and also whether this approach looks like a good way to get to the feature I mentioned, regarding XML prefixes in JSON Path tokens.

And yes, I'm expecting to need to rebase and redo a bunch of this since things are moving around. Part of the reason I'm asking for this feedback now :)

Ok, I'll try review today. Creating a struct to represent the paths makes a lot of sense. I'm unsure of calling it JSONPath, though. Because they are not really JSON Paths (as in they do not conform to the spec), but are just based on them.

Fair point about the struct name. Happy to call it something else :)

Maybe DocumentPath makes more sense, because they are paths to elements in any hierarchical document (JSON, XML, YAML) :man-shrugging:

Changes look good. Thanks for also converting to anyhow::Result as you went.

Thanks for the review! I replied to your comments on that commit.

Regarding the name of this new type, `DocumentPath` sounds appropriate but the golfer in me worries that it's too many characters :slightly_smiling_face: Do you think `DocPath`would be acceptable?

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_models-v0.0.4_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_matching-v0.9.3_ published by uglyog

:tada:

thanks Ron

```> @pact-foundation/pact@10.0.0-beta.38 build:v3 /Users/matthewfellows/development/public/pact-js > neon build --release neon info running cargo Compiling proc-macro-nested v0.1.7 Compiling mime_guess v2.0.3 Compiling pact-js-v3 v0.0.6 (/Users/matthewfellows/development/public/pact-js/native) Compiling futures-util v0.3.15 Compiling multipart v0.17.1 Compiling h2 v0.3.3 Compiling futures-executor v0.3.15 Compiling futures v0.3.15 Compiling hyper v0.14.9 Compiling hyper-rustls v0.22.1 Compiling reqwest v0.11.4 Compiling pact_matching v0.9.3 Compiling pact_mock_server v0.7.17 Compiling pact_matching_ffi v0.0.3 Compiling pact_verifier v0.10.7 error[E0432]: unresolved import `pact_matching::models::json_utils` --> /Users/matthewfellows/.cargo/registry/src/github.com-1ecc6299db9ec823/pact_verifier-0.10.7/src/lib.rs:30:28 | 30 | use pact_matching::models::json_utils::json_to_string; | ^^^^^^^^^^ could not find `json_utils` in `models` error: aborting due to previous error For more information about this error, try `rustc --explain E0432`. error: could not compile `pact_verifier````

So the update to matching breaks the verifier, it seems some packages have moved

I think i?ll need to update the `pact_verifier` package

Ah, damn, my bad

I only thought to release the matching crate

Do you want me to do that now?

I?m in there now

Just a matter of running the release script I assume?

No, it needs to be branched off the last release commit, because there are later changes that would require the model and matching crate released again

I'm doing that now

ah ok thanks

The mock service has the same problem, whilst you?re at it :laughing:

thx

If you?re feeling generous, might as well publish the latest FFIs too? (I think Adam is keen to use the new logging infra in Pact .NET)

Release all the things

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/pact_verifier-v0.10.8_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_mock_server-v0.7.18_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_mock_server_ffi-v0.1.0_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/pact_verifier_ffi-v0.0.5_ published by uglyog

looking better. I think we now have a dependency on `pact_matching_ffi` , which makes sense because of the log interface: ``` @pact-foundation/pact@10.0.0-beta.38 build:v3 /Users/matthewfellows/development/public/pact-js > neon build --release neon info running cargo Compiling pact-js-v3 v0.0.6 (/Users/matthewfellows/development/public/pact-js/native) Compiling pact_mock_server_ffi v0.1.0 error[E0432]: unresolved import `pact_matching_ffi::log::fetch_log_buffer` --> /Users/matthewfellows/.cargo/registry/src/github.com-1ecc6299db9ec823/pact_mock_server_ffi-0.1.0/src/lib.rs:92:3 | 92 | fetch_log_buffer, | ^^^^^^^^^^^^^^^^ | | | no `fetch_log_buffer` in `log` | help: a similar name exists in the module: `fetch_memory_buffer` error: aborting due to previous error For more information about this error, try `rustc --explain E0432`. error: could not compile `pact_mock_server_ffi````

Just releasing that now

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_matching_ffi-v0.0.4_ published by uglyog

I've also fixed some imports in pact-js

ah ok cool

thx

Should be all good now

thx :pray:

I?ll pull shortly

Hey folks. Pact-rust is the basis for the pact-ref-mock-server on DockerHub, right? Any chance we get an updated docker container with these latest developments? :slightly_smiling_face:

Should be able to have a look early next week. And yes, I'm pretty sure it is

Surprised it's not triggered automatically like the Ruby one. #TODO

has joined #pact-rust

:wave: Is there a list of supported rust versions or anything? I?ve tried to run a `cargo install pact_verifier_cli` and I?m getting an error that looks like a dependency version mismatch (error in thread)

``` Compiling pact_verifier_cli v0.8.5 error[E0061]: this function takes 1 argument but 0 arguments were supplied --> /Users/scottriley/.cargo/registry/src/github.com-1ecc6299db9ec823/pact_verifier_cli-0.8.5/src/main.rs:242:9 | 242 | match handle_cli().await { | ^^^^^^^^^^-- supplied 0 arguments | | | expected 1 argument | note: function defined here --> /Users/scottriley/.cargo/registry/src/github.com-1ecc6299db9ec823/pact_verifier_ffi-0.0.5/src/verifier.rs:133:14 | 133 | pub async fn handle_cli(version: &str) -> Result<(), i32> { | ^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0061`.```

this is on latest stable rust (`1.53.0`)

I?m also not sure - other than the docker image is there a way to download the already compiled binary? (I can see the readme has some release scripts for osx/windows/etc.)

Not sure about that error. Main seems to be passing in GH actions tho

ok :thumbsup: yeh I missed the verifier publishes in github

thanks

Hi, I got this error when using https://github.com/pact-foundation/pact-reference/releases/download/libpact_mock_server_ffi-v0.1.0/pact_mock_server_ffi-c.h > Uncaught FFI\ParserException: undefined C type 'PactSpecification' at line 513

Another question: We don't have something like this for pact message? > $ffi->with_specification($pactMessage, $ffi->PactSpecification_V3);

And another question: Do we want to release new version of `pact_cli` ?

Don't need it for that yet, it's only v3

I don?t actually use that header file, not sure if it?s up to date

I map them to `int` (it?s an enum that is c compatible as sequential integers)

Ah! The structs and enums have been moved to a separate library. So they are not included in the header file by default.

Is that header created by hand or automatically? Do we need it?

automatically. But I don't think we need that enum, just an integer value would work

cool, that?s what I do

My plan is to download that header file to use it in pact-php. Can I create a ticket to fix it?

I've already fixed it :smile:

@uglyog I saw your fix on doc comments. Don?t clean up my mess, I?m happy to update the README and doc comments next week on my OSS day if you like?

Already done.

Not the readme, I generally don't do documentation. :wink:

How do folks normally deal with authenticated provider endpoints when using the standalone verifier? As far as I can see I?ve got three options of: ? Load some config that disables this auth when we boot the provider app before running the verifier cli (don?t really like the idea of doing this) ? Do something in the state change endpoint to provide some auth credentials (we?d need to make sure that every interaction did some provider state setup) ? Go back to the ruby standalone verifier and use `custom-provider-header` Have I understood this correctly? (and asked in the right channel :sweat_smile:)

Normally people are using the verifier from their build, so they have control over the app and can disable the auth (using either of the methods you described).

But can you raise a github issue so we can get that option added

the `custom-provider-header` option doesn?t allow dynamic values though - is that sufficient?

one option is to use the provider state injected values, and use the state handler to return a valid auth header/token/whatever

ok, cool - thanks this is useful

I was mostly just verifying that I was on the right path

Thanks.

The custom header may work, if it supports multiple values (i.e. we?ve got some endpoints behind jwt auth, and other just behind basic)

we could generate a sort of ?magic jwt? and ?magic user/pass combo? per run or something and load them in in an env var

> one option is to use the provider state injected values, and use the state handler to return a valid auth header/token/whatever I?m not sure I understand how this would work - how would the valid auth header/token/whatever actually get injected into the requests the verifier is making?

there is a feature in v4 that allows a consumer to specify that certain properties/fields/path elements (anywhere a matcher can go) aren?t known at verification time, and are captured in an expression. The state handler is responsible for returning values to inject into the expression. When the verification step runs, it uses the values returned from the state handler, and puts them in the request

see https://pactflow.io/blog/injecting-values-from-provider-states/

ok, cool

one of the first consumers we?re using this with is unfortunately using `pact-ruby` which I think is lagging behind quite a bit

What was your provider again? I forgot why you weren't using a framework to hide this away?

the provider is an old rails app

(i.e. rails 3.2)

What features are you needing from the latest of pact?

Things like the v3 spec?s generators

and the provider value injection

We've ended up with a proxy server that sits in front of the app and injects some auth into the requests the verifier makes, this should work ok for now

I think interaction's description should not be required in this code: > $interaction = $ffi->new_interaction($pact, 'a simple request'); Because later we will set the same value again with: > $ffi->upon_receiving($interaction, 'a simple request (again)');

That's right. There was a technical reason for C++ but for others it doesn't matter

@uglyog as per the single FFI package :point_down:

So the idea I had was to just create a _new_ ffi package, that simply re-exports the useful functions of the other FFIs

That would have the upside of not impacting existing users, but also just means we have more packages

We should also have a plan to deprecate and remove the other libs

We could do the expand contract - add the new unified ffi, wait for all consumers to get on it, and then remove the old ones?

Side note, how do I build and use the `pact_mock_service_ffi` package locally? It always complains about the `pact_matching_ffi` lib being missing? I recall you mentioning some trick, but can?t find it

You mean `pact_mock_server_ffi`

How are you building it?

Running `cargo build` in that directory works for me

one sec?

the build works, it?s when I use the artifact

```--- ? Running Pact examples go test -v -tags=consumer -count=1 http://github.com/pact-foundation/pact-go/v2/examples/... dyld: Library not loaded: libpact_matching_ffi.dylib Referenced from: /var/folders/3l/vsf3kf6n3yd_p40kwn_1883c0000gn/T/go-build645829403/b001/examples.test Reason: image not found FAIL http://github.com/pact-foundation/pact-go/v2/examples 0.312s ? http://github.com/pact-foundation/pact-go/v2/examples/types [no test files] FAIL make: *** [pact] Error 1```

if I use one downloaded from github releases, it works

So I think it?s something to do with how the artifact is generated. It?s like it doesn?t contain the matching lib, and just refers to it

My copy does not link to anything else: ```$ ldd target/debug/libpact_mock_server_ffi.so linux-vdso.so.1 (0x00007ffcd57fe000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f2d4e847000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2d4e825000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2d4e6d7000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2d4e6d0000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2d4e4e4000) /lib64/ld-linux-x86-64.so.2 (0x00007f2d4fcd1000)```

Sorry, I don't have an OSX environment

Yeah, not sure why mine does! ```? pact-go git:(feat/message-metadata) ? otool -L /usr/local/lib/libpact_mock_server_ffi.dylib /usr/local/lib/libpact_mock_server_ffi.dylib: libpact_matching_ffi.dylib (compatibility version 0.0.0, current version 0.0.0) /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 59306.140.5) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1677.104.0) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1) /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)```

I?ll dig further

It?ll be a pain to test locally if the unified FFI contains all the others

Have you upgraded your rust compiler (what version are you running?)

Maybe I should buy on old refurbished macbook to help diagnose these issues

(i?ll do an update now)

```? native git:(feat/message-metadata) ? rustup -V <aws:pact-prod> rustup 1.24.2 (755e2b07e 2021-05-12) info: This is the version for the rustup toolchain manager, not the rustc compiler. info: The currently active `rustc` version is `rustc 1.53.0 (53cb7b09b 2021-06-17)````

That is the latest

ah

Rustup is now one micro version newer :wink:

@uglyog @tjones re: https://github.com/pact-foundation/pact-reference/pull/120

I just spent the last hour mucking about to support an incoming JSON payload that accepts a `pactMessageMetadata` field, and a `pactMessageContents` field, which is represented as a set of `Bytes` (to allow non-JSON payloads).

Doing this seems to be a bad idea, because I?m going to have to make a lot of changes (I thikn) to `http://messages.rs` to know what to do when it receives different content types inside the bytes. It might not be as dramatic as that, but it does feel like double handling of that sort of logic, which I can see is already present further down the line

I?m going to take a lunch break, and that will pretty much be it for the day today (meetings this arvo)

One thought I had, was to not accept an incoming JSON payload, but retrieve metadata via HTTP headers

that would be fairly convenient to do, I think, but I?m not convinced it?s a nice approach

It would be a bit awkward for users

yeah

The alternative is to make it more awkward for the JSON use case (because you need to write JSON as bytes over the wire)

Actually, if the headers were prefixed, that might be ok

So each metadata field has a different header

that?s what I was thinking

Some people I know of have JSON as metadata values

They would need to encode it into the header value

specifically, the code in `make_provider_request` is I think where it would need to change. It eventually calls `match_message` which currently accepts the `Message` that needs to be ready to go (so any bytes would need to be decoded back into their correct type, and the content-type correctly parsed etc.)

:grimacing:

gah

so would it be `PACT_MESSAGE_METADATA_<key>=<value>`

k

I?ll give that a go, but probably tonight

It does have a nice separation between data and metadata.

Which, I suppose, is what headers actually are

I was assuming that the metadata would largely be provided by the pact framework, and not by the users

As in, users provide the key/values, but ?we? (as in pact-js or whatever) decide how it gets put on the wire

Yeah, that's mostly true

But also the verifier is a CLI tool

So users could build tools around it

But I think it's ok, as long as it's documented how to properly use it

It would be a change in the JS side Tim, but easily enough I think. Thoughts?

What's the change? Using headers instead?

I think that might be the commented bit. I definitely already implemented it, when I was trying to guess at how it might be handled on the rust side

Shall we say: `PACT_MESSAGE_METADATA_<key>=<JSON encoded value>`?

https://stackoverflow.com/a/40347926/790070 ^ We have to be a bit careful with JSON in headers

I think they should be simple values, and people who want to put JSON in need to encode/decode them themselves

Actually, now that I recall, it wasn't JSON they were using, but XML :scream:

"simple values" - do you mean strings?

Because without some kind of encoding ,we can't tell the difference between `0` and `"0"`

Primitives (not collections)

How do we tell the difference between numbers and strings?

Also primitives are different in different languages

If we're expecting the consumer to handle serialisation, can we say "strings" and leave the implementation up to the user?

(also, it's not quite "strings", because the headers have some restrictions)

Metadata is represented as a hashmap of string -> string anyway

> If we?re expecting the consumer to handle serialisation, can we say ?strings? and leave the implementation up to the user? That?s what I think we should do. I actually think it?s what it currently assumes also

Pact-JVM had to change that from string -> string to string -> any

We should do the same here

Here is the issue: https://github.com/pact-foundation/pact-jvm/issues/1006

> This is a problem when integrating with messaging frameworks that also provide metadata with raw Object values instead of String (like IMessage of azure servicebus in my case) because you can't translate the pact Message to such a message representation then (at least not with hard workarounds.)

Chris. Then a header value per metadata key/value pair is not going to work, because headers are string values

I think JSON values will work (that way they retain the types). I looked at azure servicebus IMessage, and most of it is things like destination channel and correlation ids. But there are lock types and sessions as well.

99% will just be string values (like destination queue) and correlation IDs (numbers and UUIDs)

Sorry, was on a call Ron

So if each key had its own header, I don?t think that would would work, because a `0` would be represented as a `"0"`

I always thought you were a call girl, err, I mean guy

but if we smashed all of the metadata into a sinlgle header, then we could represent it as JSON

No, each key is a separate header, and the value is a JSON value

ah so then `PACT_MESSAGE_METADATA_FOO=0` = number `PACT_MESSAGE_METADATA_FOO="0"` = string?

k

We need the types if people are using type matchers

How do we do that? Do we need to encode something else into the value?

The JSON values have types

Ironic: https://pact-foundation.slack.com/archives/C9UN99H24/p1625468438328500

> The JSON values have types are you referring to the Rust side here or just commenting that if we properly encode the values the types will be correct?

When you parse a value as JSON, you get a typed value

`PACT_MESSAGE_METADATA_FOO=false` is a boolean

```pub struct MessagePact { /// Consumer side of the pact pub consumer: Consumer, /// Provider side of the pact pub provider: Provider, /// List of messages between the consumer and provider. pub messages: Vec<message::Message>, /// Metadata associated with this pact file. pub metadata: BTreeMap<String, BTreeMap<String, String>>, /// Specification version of this pact pub specification_version: PactSpecification, }``` Just so I?m clear, would we be changing `metadata` to be a `BTreeMap<String, BTreeMap<String, Value>>` ?

i.e. using the json `Value` type instead of a String?

Actually, I might make this two PRs

Step one - extract the headers into the current implementation of pure strings

step 2, refactor to allow richer objects

That sounds like a sensible plan

Before the night is out, you'll probably have 3 PRs

Maybe 4

Actually, I think `BTreeMap<String, Value>`

You're confusing the Pact metadata with the message metadata :smile:

Yes, I just realised the same thing

You could just use a `HashMap`, because order is not important

> Before the night is out, you?ll probably have 3 PRs When I?m in unfamiliar territory, I prefer to try and get an idea in front of others before going too far, so that I can get feedback on the general approach

hope it?s OK

I?ve appreciated the quick response on the last few (you too @tjones!)

That's the problem, 3 people's opinions -> 4 PRs

Checked the V4 model, and it already is the correct type ``` /// Metadata associated with this message. pub metadata: HashMap<String, Value>,```

You have to be careful with json in headers because JSON lets you have characters you can?t have in headers. There?s a discussion and a JS workaround in the stackoverflow issue I linked

headers are largely arbitrary otherwise - there?s no length requirement, and most http implementations will accept up to 8k of headers (!)

I like the ?encode as JSON? approach. But we should put a warning for implementers in the spec, because `removeNewlines(JSON.stringify(foo))` is not enough.

base64 encoded is probably a better approach

much

I think it?s also gonig to have to be a single header. The reason is that I don?t think we?ll be able to reliably deal with strange keys (e.g. if there is a space, or hyphen)

(I?ll think later when back in front of laptop)

also I think it will mess with case

We could also restrict the keys

but a single header probably makes more sense

I think it?s easier anyway

FYI I made some progress on the ?support complex values? in the metadata. Tested in go

I need to fix the compilation in the matching_ffi package, but it works

has joined #pact-rust

has joined #pact-rust

If header have multiple values we have to use `index` in `with_header` https://github.com/pact-foundation/pact-reference/blob/master/rust/pact_mock_server_ffi/src/lib.rs#L775 ? I did google and I think that multiple-value header can be present by a string with comma-separated https://stackoverflow.com/questions/32667075/multiple-values-on-http-headers, so I think `index` is not needed. Is that right?

Rust represents it internally differently though, I think for matching purposes. @uglyog care to elaborate?

While using a comma-separated string may work (the headers will be generated in that form), there are some cases where it may not work. For instance, if using a matcher, the matcher will be applied to the whole string.

We can update it to detect a comma-separated string, but there are cases where that can cause problems. It kind of has to be done on a header by header basis. For instance, headers with date values have a comma separating the day from the month part.

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_models-v0.0.5_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_matching-v0.9.4_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_matching_ffi-v0.0.5_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_mock_server-v0.7.19_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_mock_server_ffi-v0.1.1_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/pact_verifier-v0.10.9_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/pact_verifier_ffi-v0.0.6_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_ffi-v0.0.0_ published by uglyog

How to set metadata for message? I got this error: > Expected message metadata 'routing_key' to have value 'And the clowns have all gone to bed' but was '' This code return the message https://github.com/pact-foundation/pact-reference/blob/master/php/src/provider-proxy.php#L30, but I don't know how to modify it to fix the error.

Can you please show the pact that was generated?

This one https://github.com/pact-foundation/pact-php/blob/master/example/pacts/test_consumer-test_provider.json#L23

Metadata is not part of the message itself, it needs to be sent back

But I changed `version` to `3.0.0`

Yep

See https://github.com/pact-foundation/pact-reference/pull/120

Thanks, I will check

:+1:

This is an issue I got when using new `Pact FFI Library 0.0.0` > FFI\ParserException: ';' expected, got '<STRING>' at line 275

I haven't used the new all in one FFI interface yet but if you can tell us what you're doing / provide more input that might help

Otherwise I'll be able to test Pact Go this week sometime myself

I think it come from `pact.h` , around these lines: ```#ifdef __cplusplus extern "C" { #endif // __cplusplus``` I think we need to generate a file `pact-c.h` like other FFI libraries

Another thing I saw is every methods starting with `pactffi_*` , not sure it's needed

Not sure why body's type changed from `char` to `uint8_t` ```void pactffi_message_with_contents(struct MessageHandle message, const char *content_type, const uint8_t *body, size_t size);```

I think `pact_message_metadata` is causing problem. Slim framework (PHP) normalize header name into `pact-message-metadata` . I tested by rename in `http://message.rs` and it works. Do we consider rename it?

These were requested by @tjones

It?s just a convention for ensuring that there?s no collision with other C libs.

It was requested to only have 1 header file. It needs those ifdefs to be usable in C++

This is to support binary payloads

In the other libraries, we don?t bother using the header files. I don?t know about PHP, but we can simply define the bits we need

Yep. So that tells me you probably havn?t supported binary payloads in the HTTP mock service (that?s fine, but just take note)

Maybe separate into 2 functions: ? pactffi_message_with_contents ? pactffi_message_with_binary_contents What do you think?

Sadly PHP only support c's header, not cpp https://www.php.net/manual/en/ffi.cdef.php

We don?t need both though - whether you?re sending JSON or binary, it just needs to be given an array of bytes

Oh, we will have to go back to two separate header files then.

In the short term, just comment out those lines

How are you defining the FFI interface Tien? In Go and JS, I can just define the functions and types I need locally

but it probably is best there is an up-to-date c interface - does the c bindgen give that to us for free Ron?

I download it, both header and library files

So, before we generated two headers, one for C and one for C++

Also Tien - does @cfmack know you?re doing this? Might be worthing looping him in, or getting access to be able to submit PRs off the main branch? There is probably a lot of work goinsg on here, so ideally the maintainer is across it

has joined #pact-rust

But there was a discussion to only have one header (@tjones may have been in that)

Might also have been on the .Net channel

For a single header to work with C++, the C functions have to be wrapped in `extern "C" {`

@matt.fellows no he doesn't know, I didn't submit any code yet

I reckon it?s worth the two of you having a chat (even just async in #pact-php or something) to try and get aligned. The work you?re doing is great, and it would be a shame if there are barriers to getting it into the main repo - so any coaching/guidance you can get now will probably save you later!

I don't know about only one header. Having the C headers only feels like it makes sense to me, but there may be a reason it's good to have two. If we only have one, it'd be better to only have C rather than C++

Shouldn't it be `char*`?

`uint8_t*` is only probably a byte, whereas `char*` is guaranteed to be. Although, I don't think it actually matters, because we'll have 8 bit bytes on everything we're likely to be running on.

It really makes no difference, you'll have to caste one way or another. This is more an indication that it takes bytes, not characters.

Fair enough :+1:

what do you think about this?

In retrospect, I have no idea why I went with underscores.

I don?t think any language has currently implemented `_` so we could definitely change it

@uglyog care to weigh in?

No, fine with me. Other headers use dashes

exactly, NFI what I was thinking

I?ve just made the small change to support this, but a new release will be required before it?s in the wild. For now, you can pull down the changes locally Tien to validate

Will do. Thanks

It works. I can't wait for the next release

has joined #pact-rust

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/pact_verifier_cli-v0.8.6_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/pact_mock_server_cli-v0.7.5_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/pact_consumer-v0.7.7_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_models-v0.1.0_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_matching-v0.10.0_ published by uglyog

I wonder do you forget to release new version of `Pact FFI Library 0.0.1` ?

No, there is not any major changes since `0.0.0`. Are you looking for something in particular?

I'm impatiently waiting for 2 changes to be released: ? Separate `pact.h` and `pact-c.h` ? Change header `PACT_MESSAGE_METADATA` to `PACT-MESSAGE-METADATA`

Ok, the second one is in the changes, but we haven't created the two headers in the build yet

So releasing it now only has the `PACT_MESSAGE_METADATA` change

I am waiting for both, so no worry, I will wait more

has joined #pact-rust

Had a convo with @matt.fellows in another channel Looking pointers to get started with the end goal of implementing Pact consumer framework, shooting for spec v.3, in Elixir via FFI to Rust.

great! How do you import libraries into Elixir? With Rust, you?d `cargo build` the `libpact_ffi` code. That would generate a framework for you (either, .so, .dll, .a, .dlyb?). How would you pull that kind of framework file into your Elixir code/project/framework?

There are some examples calling the FFI libs form other languages: https://github.com/pact-foundation/pact-reference#other-languages

I?ve left my future-self some notes here too https://gist.github.com/surpher/bbf88e191e9d1f01ab2e2bbb85f9b528

For some implementation guidance, we?ve been using GH projects to track the high level tasks. Examples: Go: https://github.com/pact-foundation/pact-go/projects/2 JS: https://github.com/pact-foundation/pact-js/projects/3 Pact Go: internal FFI bindings here https://github.com/pact-foundation/pact-go/blob/2.x.x/internal/native/mockserver/mock_server.go and an example of it running https://github.com/pact-foundation/pact-go/blob/2.x.x/internal/native/mockserver/mock_server_test.go#L125-L162. This is internal framework, but you can see how it works. Pact .NET is also in a decent state for inspiration: https://github.com/pact-foundation/pact-net/tree/feature/4.0.0

Sorry, bad links (refactored to use the single / all-in-one FFI lib): ? https://github.com/pact-foundation/pact-go/blob/2.x.x/internal/native/mock_server.go ? https://github.com/pact-foundation/pact-go/blob/2.x.x/internal/native/mock_server_test.go

has joined #pact-rust

Hey @marko.justinek, I?ve been looking into Elixir bindings along with @pedroefajardo_pactio. As far as I?m aware, there are two ways to do FFI in Elixir that apply here. There?s the lower-level approach from Erlang (called NIFs), and a Rust-specific abstraction called https://github.com/rusterlium/rustler, which will execute `cargo build` with the right arguments and hide the complexity there. I?ve started a project with Elixir bindings (see #pact-elixir for details) and I?m trying to get Rustler configured, but I?ve had poor luck so far. I couldn?t get Rustler?s compilation to work, so I set it to just use a pre-built library file that I copied out of the `target` directory. But now I?m seeing errors that suggest that the file isn?t compiled with the right flags/configuration: ```$ mix run_mock_server # ... 12:28:46.949 [warn] The on_load function for module Elixir.Pact returned: {:error, {:bad_lib, 'Failed to find library init function: \'dlsym(0x7f85dd604160, _nif_init): symbol not found\''}}``` So at this point I?m thinking of going back through your gist (thanks, by the way!) and maybe dropping down to raw NIFs.

Aha, looks like I misunderstood something foundational about NIFs - they require instrumentation on the Rust/C/C++ side so they play nicely with the BEAM. Here?s an article that talks about https://andrealeopardi.com/posts/using-c-from-elixir-with-nifs/, and it starts by importing a header on the C side: ```#include "erl_nif.h" ``` So I think I?ll need to create a Rust shim within the Elixir project and have that depend on the library internally.

has joined #pact-rust

Hi all. I have just picked up and started using the Rust pact_verifier_cli and am running into an issue. I'm attempting to use the pact_verifier_cli to verify all pacts with a certain tag ```pact_verifier_cli ... --consumer-version-selectors="{\"tag\": \"prodlkjasdlfjlsajkdf\",\"latest\": false}"``` However it appears this flag is getting ignored and the same pact is verified no matter what data I pass. I'm not sure if I'm misusing this flag or formatting the value incorrectly or if there is a product bug. Any pointers? I also just posed this same question on stack overflow before seeing this slack channel... https://stackoverflow.com/questions/68776438/pact-verifier-cli-not-honoring-consumer-version-selectors

Or is this better to file on GitHub?

Can you please set loglevel to verbose?

These options should be available in the next release https://github.com/pact-foundation/pact-reference/blob/8d6ea58bf525e7ec23824d155551e24daccc5744/rust/pact_verifier/src/pact_broker.rs#L938

I did see the history on the repo and saw more selector facets were coming in the next release - cool stuff. Or are you saying the `--consumer-version-selectors` is not available in the current release? Even with this trace log level I do not get the same output - I don?t see that same `Sending JSON...` DEBUG message (https://github.com/pact-foundation/pact-reference/blame/8d6ea58bf525e7ec23824d155551e24daccc5744/rust/pact_verifier/src/pact_broker.rs#L408) - are we using the same version? ```$ pact_verifier_cli --version pact_verifier_cli 0.8.6 pact verifier version : v0.8.6 pact specification version: v3.0.0```

I tested with the exact same version (i.e. the current, as of today)

what does a `--loglevel trace` look like?

```12:18:39 [DEBUG] (1) pact_verifier::pact_broker: Link URL is templated 12:18:39 [DEBUG] (1) pact_verifier::pact_broker: templated URL = https://pact-broker.eng.internal.com/pacts/provider/{provider}/latest 12:18:39 [DEBUG] (1) pact_verifier::pact_broker: Looking up value for key 'provider' 12:18:39 [DEBUG] (1) pact_verifier::pact_broker: final URL = https://pact-broker.eng.internal.com/pacts/provider/KVP/latest 12:18:39 [INFO] Fetching path '/pacts/provider/KVP/latest' from pact broker 12:18:40 [DEBUG] (1) reqwest::async_impl::client: response '200 OK' for https://pact-broker.eng.internal.com/pacts/provider/KVP/latest 12:18:40 [TRACE] (5) want: [/Users/ben.kaiser/.cargo/registry/src/github.com-1ecc6299db9ec823/want-0.3.0/src/lib.rs:341] signal: Want 12:18:40 [TRACE] (5) want: [/Users/ben.kaiser/.cargo/registry/src/github.com-1ecc6299db9ec823/want-0.3.0/src/lib.rs:355] signal found waiting giver, notifying 12:18:40 [TRACE] (1) pact_verifier::pact_broker: [/Users/ben.kaiser/.cargo/registry/src/github.com-1ecc6299db9ec823/pact_verifier-0.10.9/src/pact_broker.rs:480] with_retries: attempt 2/3 is Ok(Response { url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("http://pact-broker.eng.internal.com")), port: None, path: "/pacts/provider/KVP/latest", query: None, fragment: None }, status: 200, headers: {"content-type": "application/hal+json;charset=utf-8", "date": "Mon, 16 Aug 2021 12:18:40 GMT", "strict-transport-security": "max-age=15724800; includeSubDomains", "vary": "Accept", "x-content-type-options": "nosniff", "x-pact-broker-version": "2.76.0", "content-length": "924", "connection": "keep-alive"} }) 12:18:40 [TRACE] (5) want: [/Users/ben.kaiser/.cargo/registry/src/github.com-1ecc6299db9ec823/want-0.3.0/src/lib.rs:341] signal: Want 12:18:40 [TRACE] (5) want: [/Users/ben.kaiser/.cargo/registry/src/github.com-1ecc6299db9ec823/want-0.3.0/src/lib.rs:200] poll_want: taker wants! 12:18:40 [TRACE] (5) want: [/Users/ben.kaiser/.cargo/registry/src/github.com-1ecc6299db9ec823/want-0.3.0/src/lib.rs:341] signal: Want 12:18:40 [INFO] Fetching path '/pacts/provider/KVP/consumer/AE/version/635fa55deedbc8410aeff25fcea58d6c5d9ccc30' from pact broker 12:18:40 [DEBUG] (1) reqwest::async_impl::client: response '200 OK' for https://pact-broker.eng.internal.com/pacts/provider/KVP/consumer/AE/version/635fa55deedbc8410aeff25fcea58d6c5d9ccc30 12:18:40 [TRACE] (1) pact_verifier::pact_broker: [/Users/ben.kaiser/.cargo/registry/src/github.com-1ecc6299db9ec823/pact_verifier-0.10.9/src/pact_broker.rs:480] with_retries: attempt 2/3 is Ok(Response { url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("http://pact-broker.eng.internal.com")), port: None, path: "/pacts/provider/KVP/consumer/AE/version/635fa55deedbc8410aeff25fcea58d6c5d9ccc30", query: None, fragment: None }, status: 200, headers: {"content-type": "application/hal+json;charset=utf-8", "date": "Mon, 16 Aug 2021 12:18:40 GMT", "strict-transport-security": "max-age=15724800; includeSubDomains", "vary": "Accept", "x-content-type-options": "nosniff", "x-pact-broker-version": "2.76.0", "content-length": "41720", "connection": "keep-alive"} }) 12:18:40 [TRACE] (11) want: [/Users/ben.kaiser/.cargo/registry/src/github.com-1ecc6299db9ec823/want-0.3.0/src/lib.rs:341] signal: Want 12:18:40 [TRACE] (11) want: [/Users/ben.kaiser/.cargo/registry/src/github.com-1ecc6299db9ec823/want-0.3.0/src/lib.rs:355] signal found waiting giver, notifying 12:18:40 [TRACE] (11) want: [/Users/ben.kaiser/.cargo/registry/src/github.com-1ecc6299db9ec823/want-0.3.0/src/lib.rs:341] signal: Want 12:18:40 [TRACE] (11) want: [/Users/ben.kaiser/.cargo/registry/src/github.com-1ecc6299db9ec823/want-0.3.0/src/lib.rs:200] poll_want: taker wants! 12:18:40 [TRACE] (11) want: [/Users/ben.kaiser/.cargo/registry/src/github.com-1ecc6299db9ec823/want-0.3.0/src/lib.rs:341] signal: Want 12:18:40 [DEBUG] (1) pact_verifier: Got pact with links [Link { name: "curies", href: None, templated: false, title```

is there more?

i mean there are about 11k lines

any chance of a gist or a private DM?

it says it found a Pact, so just wondering what the problem is

The issue is that the requests to the broker don?t appear to be passing the ConsumerVersionSelectors at all. I do not see the DEBUG statement `Sending JSON` as in your response to the StackOverflow. In hopes that the cargo library was incorrect I have also installed from Github but the output appears to be the same.

final update - BUG!

issue coming soon

Thanks for the troubleshooting help Matt! https://github.com/pact-foundation/pact-reference/issues/133

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_models-v0.1.1_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_matching-v0.10.1_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_mock_server-v0.7.20_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/pact_verifier-v0.10.10_ published by uglyog

[pact-foundation/pact-reference] New release _https://github.com/pact-foundation/pact-reference/releases/tag/libpact_ffi-v0.0.1_ published by uglyog

@tien.xuan.vo: 0.0.1 is now released :tada:

Some lessons from pact-js - we found it easiest to use the closest-to-c bindings we could (using node-ffi), rather than using the rust-specific bindings (which we got from neon). This was because the rust-specific bindings were less feature complete when it came to differences between the way each side handles asynchronous behaviour. Also, pragmatically the C bindings are more widely used (because they're not just for rust). Your mileage may vary

Yay! :v:

Maybe you forget to upload `pact-cpp.h` to the release?

Running these commands: ```cd pact_ffi rustup run nightly cbindgen \ --config cbindgen.toml \ --crate pact_ffi \ --output include/pact.h``` I got this error:

```ERROR: Parsing crate `pact_ffi`: couldn't run `cargo rustc --pretty=expanded`: Compile(" reference/rust/target/debug/build/ring-38bf9793e960dc3f/out` (exit status: 1)\n") ERROR: Couldn't generate bindings for /home/tien/Projects/pact-reference/rust/pact_ffi.```

The message is too long I can't post here, it's just part of it

I thought you couldn't use that one? `pact.h` does not have any C++ preprocessor definitions

yes, I don't use that one. Just wanna make sure it's not a mistake

I think this is the error: `error: Unrecognized option: 'pretty'\n\nerror: could not compile `pact_ffi`\n\nCaused by:\n process didn't exit successfully: `rustc --crate-name pact_ffi --edition=2018 pact_ffi/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type cdylib --crate-type staticlib --crate-type rlib --emit=dep-info,metadata -C embed-bitcode=no -C debuginfo=2 -Z unstable-options --pretty=expanded -C metadata=e2d01246786ccf59 -C extra-filename=-e2d01246786ccf59 --out-dir /home/tien/Projects/pact-reference/rust/target/debug/deps`

Do you know why and how can I fix it?

I found this https://www.reddit.com/r/rust/comments/2ts5z7/what_happened_to_pretty/

has joined #pact-rust

hello everyone, At work we are working to implement an Elixir (wrapper?) for the Pact provider verification making calls into the Rust (core) implementation Looking for which specific functions to bind to in order to implement our wrapper. Pact-js apparently has a beta branch that already does this, does anyone know which branch that is? I am looking at https://github.com/pact-foundation/pact-js/tree/feat/ffi-core but I am not 100% sure that?s the one

:hand: Interested in this as well!

i meant the Pact Consumer flow but i?ve been told it is easier to start with the verification part. So, looking for info on both

PactSwift is using pactffi for consumer side in PactSwiftMockServer package. https://github.com/surpher/PacSwiftMockServer Sources/MockServer.swift setup, verify, finalize are the required ones for mvp

thank you @marko.justinek

eh, only now found the link is bogus? (was typing on my mobile), here?s the permalink to the file: https://github.com/surpher/PactSwiftMockServer/blob/0a8c00bbe5fd8019ffe40cfd0618e02e1cd72a4d/Sources/MockServer.swift

```pactffi_create_mock_server(...) pactffi_mock_server_matched(...) pactffi_mock_server_mismatches(...) pactffi_write_pact_file(...) pactffi_cleanup_mock_server(...)``` This is the header file for the pactffi binary and what PactSwiftMockServer is using: https://github.com/surpher/PactSwiftMockServer/blob/0a8c00bbe5fd8019ffe40cfd0618e02e1cd72a4d/Sources/pact_ffi.h

What you use (from pactffi interface) will depend on how elixir runs your tests. I started writing PactSwift just before gradual pact build up was exposed and possible using pact_mock_server_ffi (now pactffi). PactSwift parses and generates the Pact structure as a whole and it is then passed to pactffi. XCTest also destroys my MockService instance for each and every unit test it runs so I needed a way to hold on to all the interactions (one for each unit test), and only then tell pactffi to write the contract into a file with all the interactions that were tested. You may be able to start the mock server and pass it interactions?

I wouldn't use JS as basis yet, take a look at https://github.com/pact-foundation/pact-go/tree/2.x.x/internal/native

Also Pact .NET https://github.com/pact-foundation/pact-net/tree/feature/4.0.0

Definitely provider side is easier first

Takes newline separated arguments that the CLI takes

thanks @matt.fellows

The most basic MVP for provider verification using pactffi has just succeeded on PactSwift where pacts from local directory are used to verify a provider: ? PactSwiftMockServer package that does the actual pactffi call -> https://github.com/surpher/PactSwiftMockServer/blob/4c7982bc2d65f219573d4a89e66bb98e13ccbfdc/Sources/Verifier.swift ? To be on safe side `VerificationOptions` type is used so end users are limited to how many crazy things they can do: https://github.com/surpher/PactSwiftMockServer/blob/4c7982bc2d65f219573d4a89e66bb98e13ccbfdc/Sources/Model/VerificationOptions.swift ? PactSwift interface to end users -> https://github.com/surpher/PactSwift/blob/e76187e994e4725f2cf58fbca9b0a8d81317df0e/Sources/ProviderVerifier.swift The ?ho?up a minute? moment I had was where each of the arguments that are passed to `pactffi_verify(args: string)` needed to be on its own line! Not the key-value pair, but each word. I had key-value pairs but pactffi_verify was returning an error saying I passed invalid arguments. So what https://github.com/surpher/PactSwiftMockServer/blob/4c7982bc2d65f219573d4a89e66bb98e13ccbfdc/Sources/Model/VerificationOptions.swift#L88 is replacing all spaces with `\n`. (will need revisiting and optimising once `Verifier` gets more options etc). Hope that?ll help with understanding and planning your Elixir architecture better. :thumbsup: Here?s a verified Swift (on macOS) provider running on Vapor 4:

Might makes sense for this whole community of FFI integrators getting together to discuss experience, share learnings and see how we can improve (e.g. docs)

What do we think?

That sounds like a good idea to me :slightly_smiling_face: (I'm having a very-first-steps look at the python wrapper) imo, consistency between the different implementations would be beneficial, but I'm not sure how practical that would be for different languages (error handling for example)?

There are a few approach/best practice type questions I'm wondering about, such as around how tightly coupled they are and possible future proofing. For example with the error handling (I'm not sure how likely it would be, but just as an example), each implementation is having some response and error message as a result of a non-zero return code. That is susceptible to change which could be easily missed in a new version. Would that sort of thing make sense to have say another FFI call to a function providing a map of error codes and meanings for the crate's method, rather than each implementation needing to be maintained?

I was thinking about that from the args example as well, if it could make sense to have an FFI call that lists the valid options, but I can't think how you could do that without losing the possibility of any nice typing :thinking_face:

> ./pact_verifier_cli --help > > --build-url <build-url> > URL of the build to associate with the published verification results. Can you explain a bit about this option?

Hi, I'm trying to take a look at the log output produced by the pact_ffi crate, specifically the verifier currently (this is for the python implementation). If I call pactffi_log_to_buffer() once it works fine, but if it is called again (this is after loading the lib again in another test) it comes back with a -1 - however it still seems to carry on logging to the buffer. I'm also getting some weirdness whereby the output comes back fine if running in debug but not running normally :thinking_face: ? should you be able to request logging to a buffer again? I can't see how to "stop" logging (calling to log to a file works ok) ? any way to flush/sync/etc to make sure the response is ready? (although I'm not sure if it's timing, adding a crude sleep doesn't help) As per other threads, I haven't seen log handling in the other ffi implementations so not sure preferred approach here (possible I've missed it somewhere), doing the same thing is probably preferable :slightly_smiling_face:

There's definitely a few quirks to work out

But now you can't call it twice. The method is clearly documented that way, but you're probably not reading that so wouldn't know!

I'd recommend having the rust code open so you can read the method signatures

Even if you don't speak rust, they should be legible

Also I don't think the logging methods do much on the provider side, albeit I haven't tested the new methods since they were added (they do work on the consumer side)

I saw you can't call apply twice, which the log to buffer wraps up

wasn't sure if there's a way around it :thinking_face:

My description, wasn't very clear - the idea was that it should be separate anyway rather than intending to call it twice, a test will: 1. load lib, 2. make ffi call. The problem happens when a second test is trying to do that, I was hoping it would be closed enough to not have overlap but it seems it's still there to some extent I don't know enough about CFFI to undersand :thinking_face: Anyway, for now I'll look at the file option I think - the non FFI tests check some stdout, I'm looking at mirroring them at least to some extent

What about for log levels? As far as I can see, there's no way to change the level once the logger is set initially (I'm probably focusing too much on the lower value things here, but I like to get a bit of an understanding of my surroundings before going too far). Example use case, I'd like to make sure I can control the log level when calling the lib since TRACE logs can get a bit long. I can set it, but only once (this again may be a python CFFI "issue" of me not being able to re-load the library and start again in a second test - so I've currently ended up with a bit of a singleton class which I don't really like :disappointed:)

Re "Looking for which specific functions to bind to in order to implement our wrapper", for me as well it could be helpful to have some "compliance" style compatibility matrix, although idk if that would be overkill?

Unfortunately, you can't change the log level, or I haven't found a way yet. I would recommend using debug level, not trace.

This is to capture the URL of the CI build that is running the verification

@matt.fellows @mike.geeves064 @marko.justinek I've created an initial verifier FFI prototype. You can see it being using from C here: https://github.com/pact-foundation/pact-reference/blob/master/c/provider-verifcation/src/main.c#L9

Using a handle approach means we can accumulate log entries against the handle and then provide a function to retrieve them.

@mike.geeves064 @matt.fellows all the docs are available at https://docs.rs/pact_ffi/0.0.2/pact_ffi/

Thanks, I'd found along with trying to understand the src in places. Ahhhh pointers! :open_mouth:

Nice!

Cc also @pact544 @yann.courtel @matt682 @tien.xuan.vo

:+1: trace wasn't intentional, that came out when not specifying anything else. I'll go on the basis of not changing, don't "need" to just wondering for completeness

Very nice :+1:

It will replace this code, right? > pactffi_verify(<parameters for Pact Verifier CLI>);

Apologies for essentially a rust noob question, I am just trying to play with an idea to then be able to pull something back via ffi into python, but I'm finding it far harder than expected to get a basic function working that returns a string that can be manipulated. The goal was a quick and dirty just return some JSON back as a str that could be used on the other side (I wanted to try and inspect the contents of the clap app.p.opts, for example). I've tried the following permutations of can I get anything to send back that isn't an str, but seem to have fundamentally not understood something (I remember when Java was new, I was very happy at not having to worry about pointers :smile: ). If there's a one line "you just do this" or "go read this", a pointer (ha!) would be appreciated. If it's a much more complicated "first you need to learn rust properly" I'll need to skip for now. > #[no_mangle] > pub extern "C" fn pactffi_verifier_cli_args() -> *const c_char { > let normal_str = "hello world\0"; > let string_with_a_big_s = "hello world\0".to_owned(); > let mut mut_string_with_a_big_s = "hello world\0".to_owned(); > let c_string = CString::new("hello world").unwrap(); > let c_string_to_bytes = http://c_string.as_bytes(); > let c_string_as_c_str = http://c_string.as_c_str(); > let c_string_as_c_str_to_str = http://c_string_as_c_str.to_str().unwrap(); > let c_str = CStr::from_bytes_with_nul(b"hello world c_str\0"); > > http://normal_str.as_ptr() as *const c_char // works > // http://string_with_a_big_s.as_str().as_ptr() as *const c_char // doesn't work > // http://mut_string_with_a_big_s.as_str().as_ptr() as *const c_char // doesn't work > // http://c_string.as_ptr() as *const c_char // doesn't work > // http://c_string_to_bytes.as_ptr() as *const c_char // doesn't work > // http://c_string_as_c_str.as_ptr() as *const c_char // doesn't work > // http://c_string_as_c_str_to_str.as_ptr() as *const c_char // doesn't work > // c_str.unwrap().as_ptr() as *const c_char > }

So far rust is making me sad :smiling_face_with_tear: It's been a long time since I looked properly at something more low level, I have been living here for a while: https://xkcd.com/353/ :smile:

The problem is that most of the data is allocated on the stack, and so will discarded once the function returns.

```// This is a static string, probably pointing to fixed memory. let normal_str = "hello world\0"; // This creates a String Struct, which owns it's data. Will copy the string and destroy the data when the function returns let string_with_a_big_s = "hello world\0".to_owned(); // This is the same as above, but the variable is mutable (you can change it's contents). let mut mut_string_with_a_big_s = "hello world\0".to_owned(); // This creates a CString struct, which owns it's contents, but will also be disposed when the function returns. // It is the same as a String struct, but the data is NULL terminated let c_string = CString::new("hello world").unwrap(); // This gets a slice (static array) of the string bytes. Also allocated in the stack. let c_string_to_bytes = c_string.as_bytes(); // This gets a CStr slice (same as a str slice, but is NULL terminated). Still on the stack. let c_string_as_c_str = c_string.as_c_str(); // This converts the cstr slice into a str slice (array of characters, not null terminated). Still on the stack. let c_string_as_c_str_to_str = c_string_as_c_str.to_str().unwrap(); // This creates a CStr from a null terminated array of bytes. Also on the stack. let c_str = CStr::from_bytes_with_nul(b"hello world c_str\0");```

The magic method is `CString::into_raw()`

> Consumes the CString and transfers ownership of the string to a C caller.

It does this by allocating the CString struct on the Rust heap, and then returning the pointer. It won't be disposed of when the function returns.

Internally, it is using a Box, which is a smart pointer to data on the heap

Thanks Ron. Mike, I've definitely committed a few pointer sins to the project already so your bemusement is not uncommon

Boundaries are hard!

Thanks thanks! I will try to digest and take another look later this eve :slightly_smiling_face: Boundaries are hard! :grinning: Funny when lessons come back, like with trig "I'll never need that when I'm older", 10 years later calculating the angle from a satellite to figure out how much "shadow" there is from a tree over a field. "I'll never need pointers again! Java is the future!" Said I 21 years ago :joy:

:party_parrot: Apparently I had not tried all the possible things :smile: > let mut str_1 = "hello".to_owned(); > let str_2 = "world"; > > str_1.push_str(" "); > str_1.push_str(str_2); > > let c_str = CString::new(str_1).unwrap(); > c_str.into_raw() as *const c_char Success! Thanks for that, I can concatenate and return strings! into_raw() is indeed magical :smile: Definitely a bit of reading on heaps and stacks needed going into Rust, vs stumbling through as works well enough in py :slightly_smiling_face:

This makes me laugh. It is amusing that it was so much easier creating and manipulating structs and then creating some JSON from it...than just returning a string. Tableflip :smile: I am back to having fun now

I have a question/proposal on approach for some of the FFI work, very much just a poc and not in any way final code, just playing with an idea :) I've made a quick and dirty additional FFI function "pactffi_verifier_cli_args" in the Rust verifier: https://github.com/mikegeeves/pact-reference/pull/1/files#diff-acb08ed5a8b61dfc509747740c1c045f39c31f59105bb0290a36c7c911252254 This looks at the clap arguments defined in the Rust code and for now extracts: the argument long name, if there is a short single character option and the help. The function then returns this as a JSON string. It's more complicated than this ofc - multiple, defaults, types and so on - but just to demonstrate.. On the python side, for the CLI wrapper, I'm then just calling that function and using it to programatically setting up the click options for calling via CLI: https://github.com/mikegeeves/pact-python/pull/1/files#diff-4d935290cd4b707d3487eda5c7a90daf7c5f79c22d85bba238f218068d501e05 This is then nicely giving the help options without having to manually add them all in (snipped): > $ pact-verifier --help > Usage: pact-verifier [OPTIONS] > > Options: > --request-timeout TEXT Sets the HTTP request timeout in > milliseconds for requests to the target API > and for state change requests. > --include-wip-pacts-since TEXT Allow pacts that don't match given consumer > selectors (or tags) to be verified, without > causing the overall task to fail. For more > information, see https://pact.io/wip > <snip> > -u, --url TEXT URL of pact file to verify (can be repeated) > -d, --dir TEXT Directory of pact files to verify (can be > repeated) > -f, --file TEXT Pact file to verify (can be repeated) > -l, --loglevel TEXT Log level (defaults to warn) > --help Show this message and exit. The idea here being that at least some benefit from having the single library being shared is lost if there's then a dependency for each implementation to maintain the sets of arguments and descriptions and so on. It's an extra point of failure for e.g. typo fix, extra arg, arg removed, when for the most part (some more complicated arguments sure, but for the simple ones) the wrapper only really needs to dumbly pass them through. On the Rust side if there's anything bad it will handle it there. Half way could be each version just grabbing the JSON and at least then being able to identify if there is a change which may need to be actioned, that would be simple enough to test for. Thoughts? Any value in trying to progress this? There's way more to look at but I thought a quick poc to explain would be helpful for at least a discussion. No offence if the consensus is an abomination (as my first ever Rust code is for sure :smile: thank you again@uglyog !)

see also me attempting to fix a strange memory bug that only appeared on CI: https://github.com/pact-foundation/pact-reference/commits/master?after=50fcd409d98c92d6d3ff2034e83ae547122d07f5+244&branch=master

Turns out memory layout once you leave the safety of Rust is hard :stuck_out_tongue:

:D CI definitely painful, I'm glad you can squash commits to hide what went on

hehe

"why do you have 300 commits with the message 'sad face'" during a code review, fun times. Ahh which reminds me, there was a ticket for GitLab examples somewhere I think :thinking_face: (on the list of things I didn't quite get onto in the past year)

Looks fine to me. Just remember the JSON string will be allocated on the Rust heap, and will need to be freed with the `pactffi_free_string` function once done with it on the Python side.

I'll have a look at some of the other option types, I've added in possible_values which seems to work ok as well. > -l, --loglevel [error|warn|info|debug|trace|none] Will look into the pactffi_free_string, I've seen the warnings that it should be used but haven't seen/tried it. Have moved the code over to http://mod.rs from http://verifier.rs, I assume it's supposed to go there instead? I am not too sure about tests for Rust at all :smile:

Also, I've created #libpact_ffi-users - since there's quite a bit of discussion about the rust pact ffi bindings in the different language channels, but the discussions cover quite a bit of the same ground. Please join if this is useful or of interest to you!

We also have this new guideline (on my todo list is to do a pass over the rust core and make sure we're sticking to it): https://github.com/pact-foundation/pact-specification#logging-in-a-pact-library

Fixed by running `cargo install cbindgen` to update cbindgen from `v0.19.0` to `v0.20.0`

I am trying this and I think some parameter are missing like: ```--state-change-url http://localhost:8000/change-state```

Unless don't remove `pactffi_verify` so we can use parameters

It might be the case. I think it?s just a POC to show how that might work as a replacement for the current ?all in one? function, which is less than ideal

I haven't implemented all the options yet

@uglyog to check, on the python side I am adding this to the list of FFI functions to expose: > // mock_server > void pactffi_free_string(char *); as part of the others declared like this: > PactFFI.ffi.cdef( > """ > // root crate > char *pactffi_version(void); > > // verifier > int pactffi_verify(char *); > > // mock_server > void pactffi_free_string(char *); > > // log > int pactffi_log_to_file(char *, int); > > // experimenting > char *pactffi_verifier_cli_args(void); > """ > ) and then in my python code using it, I'm then just calling it like this: > result = self.lib.pactffi_verifier_cli_args() > cli_args_json = Arguments(**json.loads(self.ffi.string(result).decode("utf-8"))) > self.lib.pactffi_free_string(result) Is that correct? It works ok, but I am not sure how to verify that the memory is being freed correctly? (I am a little nervous about the pactffi_verifier_cli itself, if there is anything else I should be doing to clean up there too :thinking_face: )

It should be good as long as you call the method. No need to verify that the Rust memory management works :smile:

:+1:

Reviewed the PR. There are some minor things that can be improved, but it looks good to me

Awesome, thanks. Comments/improvements to make very welcome

Back at a PC so have made the updates, I'd missed a couple of the compiler warnings on /// docs for the structs which are added too. For my next attempt I may try editing in something other than pycharm which does work but possibly isn't ideal :smile: What are the conventions here on hitting merge / dealing with comments? Previously I've worked with teams where for example only the person raising a comment should then resolve them, other times the dev resolves after updating. Similar with when to merge (e.g. only after comments are all resolved, other times as soon as there's approval)

@uglyog thank you for taking the time to explain detail of some basics to a newbie, appreciate it :slightly_smiling_face: :taco:

I'm happy to have the PR merged when the comments are addressed. If you're confident you've addressed them, you can resolve them

:+1: done

Hopefully I didn't break anything :thinking_face:

Oh wait, I haven't since that was just the draft in my fork, approval needed over here: https://github.com/pact-foundation/pact-reference/pull/136

I forgot initially it was just looking at my fork as a poc/explanation rather than expecting the code to actually go in :smile:

I can?t quite pinpoint the issue but running a `cargo install pact_verifier_cli` today is failing whereas on 8/23 it was successful. ``` > [2/2] RUN cargo install --version 0.8.7 pact_verifier_cli: #5 0.979 Updating http://crates.io index #5 28.38 Downloading crates ... #5 28.65 Downloaded pact_verifier_cli v0.8.7 #5 29.03 Installing pact_verifier_cli v0.8.7 #5 29.81 Downloading crates ... ... #5 32.29 Compiling libc v0.2.101 #5 32.29 Compiling cfg-if v1.0.0 #5 32.29 Compiling autocfg v1.0.1 #5 32.60 Compiling proc-macro2 v1.0.29 #5 33.22 Compiling unicode-xid v0.2.2 #5 33.25 Compiling memchr v2.4.1 #5 33.25 Compiling syn v1.0.76 #5 33.39 Compiling log v0.4.14 #5 33.62 Compiling cc v1.0.70 #5 33.70 Compiling serde_derive v1.0.130 #5 33.70 Compiling serde v1.0.130 #5 34.12 Compiling once_cell v1.8.0 #5 34.18 Compiling version_check v0.9.3 #5 34.51 Compiling pin-project-lite v0.2.7 #5 34.65 Compiling futures-core v0.3.17 #5 34.72 Compiling untrusted v0.7.1 #5 34.95 Compiling parking_lot_core v0.8.5 #5 34.96 Compiling proc-macro-hack v0.5.19 #5 35.29 Compiling spin v0.5.2 #5 35.36 Compiling smallvec v1.6.1 #5 35.40 Compiling proc-macro-nested v0.1.7 #5 35.50 Compiling futures-task v0.3.17 #5 35.68 Compiling scopeguard v1.1.0 #5 35.79 Compiling futures-channel v0.3.17 #5 35.82 Compiling futures-sink v0.3.17 #5 35.84 Compiling itoa v0.4.8 #5 35.98 Compiling lazy_static v1.4.0 #5 36.07 Compiling fnv v1.0.7 #5 36.12 Compiling pin-utils v0.1.0 #5 36.14 Compiling regex-syntax v0.6.25 #5 36.22 Compiling futures-io v0.3.17 #5 36.25 Compiling slab v0.4.4 #5 36.47 Compiling hashbrown v0.11.2 #5 36.72 Compiling ppv-lite86 v0.2.10 #5 37.14 Compiling ryu v1.0.5 #5 37.22 Compiling httparse v1.5.1 #5 37.60 Compiling tinyvec_macros v0.1.0 #5 37.66 Compiling base64 v0.13.0 #5 37.73 Compiling getrandom v0.1.16 #5 38.13 Compiling matches v0.1.9 #5 38.26 Compiling semver v1.0.4 #5 38.53 Compiling percent-encoding v2.1.0 #5 38.72 Compiling pkg-config v0.3.19 #5 39.15 Compiling try-lock v0.2.3 #5 39.30 Compiling serde_json v1.0.67 #5 39.71 Compiling encoding_rs v0.8.28 #5 40.02 Compiling unicode-bidi v0.3.6 #5 40.88 Compiling httpdate v1.0.1 #5 41.64 Compiling openssl-probe v0.1.4 #5 42.24 Compiling tower-service v0.3.1 #5 42.40 Compiling mime v0.3.16 #5 42.51 Compiling ucd-trie v0.1.3 #5 43.51 Compiling strsim v0.10.0 #5 44.06 Compiling anyhow v1.0.43 #5 44.26 Compiling maplit v1.0.2 #5 44.42 Compiling ident_case v1.0.1 #5 44.61 Compiling bitflags v1.3.2 #5 44.62 Compiling minimal-lexical v0.1.3 #5 44.76 Compiling peresil v0.3.0 #5 45.00 Compiling remove_dir_all v0.5.3 #5 45.13 Compiling ipnet v2.3.1 #5 45.49 Compiling typed-arena v1.7.0 #5 45.71 Compiling either v1.6.1 #5 45.96 Compiling fixedbitset v0.4.0 #5 46.95 Compiling safemem v0.3.3 #5 47.22 Compiling indextree v4.3.1 #5 47.69 Compiling rustversion v1.0.5 #5 48.13 Compiling hex v0.4.3 #5 48.34 Compiling bytecount v0.6.2 #5 48.68 Compiling quick-error v1.2.3 #5 48.85 Compiling ansi_term v0.12.1 #5 48.88 Compiling async-trait v0.1.51 #5 49.32 Compiling difference v2.0.0 #5 49.81 Compiling termcolor v1.1.2 #5 50.49 Compiling unicode-width v0.1.8 #5 50.64 Compiling ansi_term v0.11.0 #5 50.88 Compiling vec_map v0.8.2 #5 51.10 Compiling humantime v2.1.0 #5 51.28 Compiling strsim v0.8.0 #5 51.89 Compiling zeroize v1.4.1 #5 52.19 Compiling instant v0.1.10 #5 52.30 Compiling futures-macro v0.3.17 #5 52.59 Compiling tokio v1.11.0 #5 52.72 Compiling indexmap v1.7.0 #5 52.87 Compiling futures-util v0.3.17 #5 53.00 Compiling num-traits v0.2.14 #5 53.20 Compiling num-integer v0.1.44 #5 53.64 Compiling unicase v2.6.0 #5 53.73 Compiling nom v7.0.0 #5 53.93 Compiling ring v0.16.20 #5 54.12 Compiling lock_api v0.4.5 #5 54.13 Compiling tracing-core v0.1.19 #5 54.57 Compiling tinyvec v1.3.1 #5 54.86 Compiling form_urlencoded v1.0.1 #5 55.47 Compiling onig_sys v69.7.0 #5 55.94 Compiling pest v2.1.3 #5 56.05 Compiling sxd-document v0.3.2 #5 56.20 Compiling itertools v0.10.1 #5 58.35 Compiling textwrap v0.11.0 #5 63.99 Compiling tracing v0.1.26 #5 67.20 Compiling unicode-normalization v0.1.19 #5 70.34 Compiling semver-parser v0.10.2 #5 77.09 Compiling quote v1.0.9 #5 77.70 Compiling signal-hook-registry v1.4.0 #5 78.07 Compiling num_cpus v1.13.0 #5 78.42 Compiling getrandom v0.2.3 #5 79.38 Compiling socket2 v0.4.1 #5 79.46 Compiling time v0.1.44 #5 79.75 Compiling fs2 v0.4.3 #5 80.17 Compiling atty v0.2.14 #5 80.33 Compiling aho-corasick v0.7.18 #5 80.83 Compiling buf_redux v0.8.4 #5 81.51 Compiling twoway v0.1.8 #5 82.04 Compiling mio v0.7.13 #5 83.47 Compiling want v0.3.0 #5 83.87 Compiling fern v0.6.0 #5 84.52 Compiling os_info v3.0.7 #5 86.48 Compiling lenient_semver_version_builder v0.4.2 #5 87.57 Compiling idna v0.2.3 #5 88.93 Compiling semver v0.11.0 #5 91.24 Compiling petgraph v0.6.0 #5 94.59 Compiling parking_lot v0.11.2 #5 95.99 Compiling rand_core v0.6.3 #5 96.51 Compiling uuid v0.8.2 #5 96.77 Compiling rand_core v0.5.1 #5 97.23 Compiling clap v2.33.3 #5 97.49 Compiling regex v1.5.4 #5 107.1 Compiling pact_ffi v0.0.2 #5 107.5 Compiling mime_guess v2.0.3 #5 108.7 Compiling lenient_semver_parser v0.4.2 #5 109.3 Compiling url v2.2.2 #5 114.1 Compiling sct v0.6.1 #5 114.7 Compiling webpki v0.21.4 #5 116.4 Compiling onig v6.2.0 #5 117.8 Compiling tree_magic_mini v3.0.2 #5 119.0 Compiling chrono v0.4.19 #5 123.2 Compiling rand_chacha v0.3.1 #5 123.3 Compiling darling_core v0.13.0 #5 124.1 Compiling rand_chacha v0.2.2 #5 124.7 Compiling env_logger v0.8.4 #5 129.3 Compiling tokio-macros v1.3.0 #5 129.9 Compiling thiserror-impl v1.0.29 #5 133.6 Compiling parse-zoneinfo v0.3.0 #5 133.8 Compiling lenient_semver v0.4.2 #5 133.9 Compiling ct-logs v0.8.0 #5 134.1 Compiling rustls v0.19.1 #5 134.3 Compiling webpki-roots v0.21.1 #5 134.5 Compiling simplelog v0.9.0 #5 135.3 Compiling rand v0.8.4 #5 136.9 Compiling rand v0.7.3 #5 137.4 Compiling darling_macro v0.13.0 #5 139.2 Compiling thiserror v1.0.29 #5 143.5 Compiling chrono-tz v0.5.3 #5 144.1 Compiling pact_models v0.1.3 #5 144.7 Compiling rand_regex v0.15.1 #5 145.3 Compiling tempfile v3.2.0 #5 146.9 Compiling rustls-native-certs v0.5.0 #5 146.9 Compiling darling v0.13.0 #5 147.0 Compiling futures-executor v0.3.17 #5 147.6 Compiling bytes v1.1.0 #5 149.1 Compiling serde_urlencoded v0.7.0 #5 152.8 Compiling multipart v0.17.1 #5 152.9 Compiling serde_with_macros v1.5.0 #5 154.8 Compiling futures v0.3.17 #5 156.8 Compiling http v0.2.4 #5 162.3 Compiling serde_with v1.10.0 #5 164.6 Compiling http-body v0.4.3 #5 165.0 Compiling tokio-util v0.6.8 #5 166.2 Compiling tokio-rustls v0.22.0 #5 166.5 Compiling h2 v0.3.4 #5 176.0 Compiling hyper v0.14.12 #5 184.1 Compiling hyper-rustls v0.22.1 #5 184.3 Compiling reqwest v0.11.4 #5 191.4 Compiling pact_matching v0.10.3 #5 215.7 Compiling pact_mock_server v0.7.20 #5 277.1 Compiling pact_verifier v0.10.11 #5 278.2 error[E0004]: non-exhaustive patterns: `&None` not covered #5 278.2 --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/pact_verifier-0.10.11/src/pact_broker.rs:293:33 #5 278.2 | #5 278.2 293 | Some(ref auth) => match auth { #5 278.2 | ^^^^ pattern `&None` not covered #5 278.2 | #5 278.2 ::: /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/pact_models-0.1.3/src/http_utils.rs:18:3 #5 278.2 | #5 278.2 18 | None #5 278.2 | ---- not covered #5 278.2 | #5 278.2 = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms #5 278.2 = note: the matched value is of type `&HttpAuth` #5 278.2 #5 278.2 error[E0004]: non-exhaustive patterns: `&None` not covered #5 278.2 --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/pact_verifier-0.10.11/src/pact_broker.rs:430:31 #5 278.2 | #5 278.2 430 | Some(ref auth) => match auth { #5 278.2 | ^^^^ pattern `&None` not covered #5 278.2 | #5 278.2 ::: /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/pact_models-0.1.3/src/http_utils.rs:18:3 #5 278.2 | #5 278.2 18 | None #5 278.2 | ---- not covered #5 278.2 | #5 278.2 = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms #5 278.2 = note: the matched value is of type `&HttpAuth` #5 278.2 #5 278.4 error: aborting due to 2 previous errors #5 278.4 #5 278.4 For more information about this error, try `rustc --explain E0004`. #5 278.4 error: failed to compile `pact_verifier_cli v0.8.7`, intermediate artifacts can be found at `/tmp/cargo-installs3DdhF` #5 278.4 #5 278.4 Caused by: #5 278.4 could not compile `pact_verifier` #5 278.4 #5 278.4 To learn more, run the command again with --verbose. ------ executor failed running [/bin/sh -c cargo install --version 0.8.7 pact_verifier_cli]: exit code: 101```

`pact_matching` crate update was released. It must have accidentally contained a breaking change.

I have released `pact_verifier` crate, which fixes this issue

Is `url` in `pactffi_verifier_set_provider_state` required? I'm thinking about adding this for it: ``` EXIT_SUCCESS } { EXIT_FAILURE }```

I don't think it is

What would that do? All I see is it might pass or might fail :rolling_on_the_floor_laughing:

But not when

It's related to this conversation https://github.com/pact-foundation/pact-reference/pull/139#discussion_r704606269

If `url` is optional, then I won't add that block of code

`url` is optional, in the sense that without it the provider states won't be invoked, they are ignored. But I think it should be required `pactffi_verifier_set_provider_state` because otherwise there is no point in calling that method.

ahem. next time I will try and stick with a single message rather than the steps while going through, it looks like there is a lot but it was all just part of one thing :open_mouth:

Ah yeah. Any commit message with `feat` or `fix` ends up in the changelog

:slightly_smiling_face: Indeed. I come from a world where every branch was squashed during merge so just the single commit :smile: Unexpected consequence of small and frequent commits!

An advantage of not squashing is that you aren't discouraged from fixing unrelated things you notice while working - you just make those separate commits, named appropriately

I mean, I've never seen people discouraged from fixing unrelated things, only discouraged from taking on a code review :smile:

Need to "practice" partial commits and modifying commits before pushing a bit more :thinking_face:

Why not use the index? `git add` will do your partial commit

I mean code chunks rather than file level

Any chance you could do a release of the CLI also Ron? Someone was asking for it so they could do provider verification with branches

Yeah, I have to release all the things to remove the beta versions

Just checked the changes, you only made the branches change to the FFI libs and not the CLI

Was the person asking for the change with the CLI?

hmm, did I not do that. Bad me

yes, they wanted CLI

Lucky they are asleep, probably, and I can delete my message telling them it?s ready :laughing:

Remember how I fixed the horrible dependency problem by duplicating the clap args?

:point_up:

?I do now

has joined #pact-rust

Do you miss `pact.h` and `pact-cpp.h` in this release https://github.com/pact-foundation/pact-reference/releases/tag/libpact_ffi-v0.1.0 ?

Let me check, it should have been generated

Looks like the release failed to generate them. I'll update it and try work out what happened.

@matt.fellows :point_up:

danke

just need the FFI and then I?m sweet I think

It's still missing in 0.1.1, but at least I can see them in 0.1.0. Thanks

updated

Heads up @tjones @yann.courtel @pact544 and @tien.xuan.vo, this release has a new pointer attribute (`interaction_type` ) on the `InteractionHandle` which resulted in a segfault for Pact Go when I ran it. Wasn?t too difficult to track down, and may not actually cause issues for you. @uglyog wondering if we should create an acceptance suite for the FFI that would catch this. I?m not that familiar with approaches here, if that?s something we can statically check or if having a fully fledged c consumer suite that links to it would be a good idea?

has joined #pact-rust

According to rust?s package manager 0.x is a breaking change, so I think it was marked correctly (but maybe not obviously)

interesting. That just raises more questions, I think the FFI interface should be semver (I?m assuming that?s the case!) but we haven?t actually ever discussed that that I can recall

the main point was just sharing that info, so you don?t have to re-discover it

It looks like the kind of change that is fairly innocuous and hard to catch (i.e. the FFI API looks the same if just look at the types/signatures)

and because it?s FFI, it just blows up if you call it (one of the downsides of FFI)

Hmmm I?m also finding that the JSON bodies are being stringified in this release. I?ll create a thread, it could be something dumb I?m doing :point_down:

Thanks for the heads-up!

I have small pact acceptance suite in Pact Go that tests that go can call the main FFI methods. The one that runs through a basic lifecycle is producing this pact file: ```? native git:(2.x.x) ? cat /var/folders/xj/rmgl_kbn1qzb9953tw7lv_yc0000gn/T/pact-go123408037/test-http-consumer-test-http-provider.json <aws:pact-prod> { "consumer": { "name": "test-http-consumer" }, "interactions": [ { "description": "some interaction", "key": "8369cdf3b43ff542", "pending": false, "providerStates": [ { "name": "some state" } ], "request": { "method": "GET", "path": "/products" }, "response": { "body": { "content": "{\"age\":23,\"alive\":true,\"name\":\"some name\"}", "contentType": "*/*", "encoded": false }, "headers": { "Content-Type": [ "application/json" ] }, "matchingRules": { "body": { "$.name": { "combine": "AND", "matchers": [ { "match": "type" } ] } } }, "status": 200 }, "type": "Synchronous/HTTP" } ], "metadata": { "pactRust": { "ffi": "0.1.2", "mockserver": "0.8.2", "models": "0.2.1" }, "pactSpecification": { "version": "4.0" } }, "provider": { "name": "test-http-provider" } }```

there are at least 2 issues: 1. It doesn?t seem to respect the `pactffi_with_specification` method at all, and always serialises a v4 pact 2. the JSON body seems to be stringified and when it is verified the verification fails because it?s comparing text and the formatting/values are different

It checks the content type, but for some reason is still doing a text comparison on the response: ``` A request to do a foo returns a response which has status code 200 (OK) includes headers "Content-Type" with value "application/json" (OK) has a matching body (FAILED) [2021-11-16T11:03:06Z ERROR pact_verifier] Failed to load pact - Failed to load pact '/Users/matthewfellows/go/src/github.com/pact-foundation/pact-go/examples/pacts/PactGoV2ConsumerMatch-V2ProviderMatch.json' - No such file or directory (os error 2) Failures: 1) Verifying a pact between PactGoV3Consumer and V3Provider Given User foo exists - A request to do a foo 1.1) has a matching body $ -> Expected text 'Some(b"{\"accountBalance\":123.76,\"arrayContaining\":[\"string\",1,{\"foo\":\"bar\"}],\"datetime\":\"2020-01-01\",\"equality\":\"a thing\",\"id\":12,\"itemsMin\":[\"thereshouldbe3ofthese\",\"thereshouldbe3ofthese\",\"thereshouldbe3ofthese\"],\"itemsMinMax\":[27,27,27,27,27],\"lastName\":\"Sampson\",\"name\":\"Billy\",\"superstring\":\"foo\"}")' but received 'Some(b"\n\t\t\t{\n\t\t\t\t\"accountBalance\": 123.76,\n\t\t\t\t\"datetime\": \"2020-01-01\",\n\t\t\t\t\"equality\": \"a thing\",\n\t\t\t\t\"id\": 12,\n\t\t\t\t\"itemsMin\": [\n\t\t\t\t\t\"thereshouldbe3ofthese\",\n\t\t\t\t\t\"thereshouldbe3ofthese\",\n\t\t\t\t\t\"thereshouldbe3ofthese\"\n\t\t\t\t],\n\t\t\t\t\"itemsMinMax\": [\n\t\t\t\t\t27,\n\t\t\t\t\t27,\n\t\t\t\t\t27,\n\t\t\t\t\t27,\n\t\t\t\t\t27\n\t\t\t\t],\n\t\t\t\t\"lastName\": \"Sampson\",\n\t\t\t\t\"name\": \"Billy\",\n\t\t\t\t\"superstring\": \"foo\",\n\t\t\t\t\"arrayContaining\": [\n\t\t\t\t\t\"string\",\n\t\t\t\t\t1,\n\t\t\t\t\t{\n\t\t\t\t\t\t\"foo\": \"bar\"\n\t\t\t\t\t}\n\t\t\t\t]\n\t\t\t}")'```

(note this is a *different pact file* than what is being verified, but the other is a long longer because of matching rules. The same set of symptoms though)

So, I think I?ve fixed the serialisation issue. I?ll submit a WIP fix to see if it?s the root cause or just a proximate one

as for spec version, it seems we?ve now migrated to the `V4Pact` struct, which doesn?t have anywhere to set the spec version (because, presumably, it is always V4)

we track the FFI spec version here: ```pub struct PactHandleInner { pub(crate) pact: V4Pact, pub(crate) mock_server_started: bool, pub(crate) specification_version: PactSpecification }``` but because the `specification_version` property is not ever passed on to the pact itself, it obviously won?t ever serialise another version

I think the problem here is that those structs are meant to be opaque structs and the internals are not meant to be exposed via FFI. They should just be typed pointers.

I'll look into the cbingen config to see why they are exposing the internals.

thanks, yeah it does look like implementation detail

the PR fixes the JSON serialisation issue, but not sure how to tackle the spec version

Oh, I was on the assumption we were passing pointers, but the FFI functions are passing the actual structs. Sorry, my bad. I trying `#[repr(transparent)]` with the handles, which will represent the handles as an opaque type on the other side of the FFI boundary. There are integration tests that test the FFI functions from C, but they don't test all the functions, they only run on Linux agents and they only test from a simple C consumer.

cool, let us know. I think a general pointer type without knowing the details makes more sense from the outside so we don?t leak implementation details / break things etc.

but also, I know less about those details.

> There are integration tests that test the FFI functions from C, but they don?t test all the functions, they only run on Linux agents and they only test from a simple C consumer. what would an ideal version look like? Perhaps it?s something we can get assistance from the general community with, including others (I?m conscious you have the main maintainer responsibility and there is a _lot_ in the core at the moment)

Is the V4 pact file issue when using it with a mock server? Ie. calling `pactffi_write_pact_file`?

yeah

if you run just this test (`http_consumer_feature_test`) in the ffi package you can see the output in `/tmp/pact/http-consumer?json`

Ok, the issue is the spec version is stored against the handle, and the mock server knows nothing about that. We can change the mock server, but that will require changing a lot of the mock server functions. I'm creating a new function `pactffi_pact_handle_write_file` which takes the handle, so it knows the spec version.

Yeah, it?s just stored on the handle at the moment and doesn?t actually go anywhere

any reason not to just update the existing FFI method? Either way on an upgrade it won?t functionally work unless code is changed

We need to update all the mock server FFI methods (there are a few, based on inputs and whether it's HTTP or HTTPS). It will be a breaking change.

Previous me provided for these types of problems, and introduced the functions `start_mock_server_with_config`. So if we use those, we just need to add the spec version to the config, and no breaking changes!!! :tada:

Thanks last Ron

`s/last/past`

`0.1.2` is looking much better Ron

I?ve noticed a couple of the versions in the metadata are escaped: ``` "metadata": { "pactRust": { "ffi": "\"0.1.2\"", "mockserver": "\"0.8.3\"", "models": "0.2.1" }, "pactSpecification": { "version": "3.0.0" } },```

Also I have a failing message test, i?ll let you know what it found

the message pact fn?s seem to be getting null pointers received, just trying to work out why. Compiling locally from master I get some different output.

Ah, there is a 0.1.3 but not published yet. Cool, working with that FFI signature?

OK, the issue was that I hadn?t updated the message handle types, which meant go was sending more stuff into the method signature and causing strange issues with converting strings.

Looks like we have a green build, thanks Ron! :rocket:

Hm, I've pushed up a tiny fix, which I think looks ok, although I'm not sure if this is the best way to add in (Rust knowledge still very low), also a little wary that this is a change of behaviour so could cause breakage, even if the current behaviour wasn't as expected I'm seeing what looks like the --state-change-teardown flag not working properly, master branch of pact-reference, unless I totally misunderstood something :smile: Default: > $ ./rust/target/debug/pact_verifier_cli -d /home/mgeeves/dev/GitHub/mikegeeves/pact-foundation/pact-python/examples/pacts --loglevel info -p 8000 -s http://localhost:8000/_pact/provider_states > > Verifying a pact between UserServiceClient and UserService > *09:32:25 [INFO] Running provider state change handler 'UserA exists and is not an administrator' for 'a request for UserA'* > Given UserA exists and is not an administrator > 09:32:25 [INFO] Running provider verification for 'a request for UserA' > 09:32:25 [INFO] Sending request to provider at http://localhost:8000/ > 09:32:25 [INFO] Received response: HTTP Response ( status: 200, headers: Some({"content-length": ["134"], "server": ["uvicorn"], "date": ["Mon", "06 Dec 2021 09:32:24 GMT"], "content-type": ["application/json"]}), body: Present(134 bytes, application/json) ) > 09:32:25 [INFO] comparing to expected response: HTTP Response ( status: 200, headers: Some({}), body: Present(134 bytes) ) > *09:32:25 [INFO] Running provider state change handler 'UserA exists and is not an administrator' for 'a request for UserA'* > *09:32:25 [INFO] Running provider state change handler 'UserA does not exist' for 'a request for UserA'* > Given UserA does not exist > 09:32:25 [INFO] Running provider verification for 'a request for UserA' > 09:32:25 [INFO] Sending request to provider at http://localhost:8000/ > 09:32:25 [INFO] Received response: HTTP Response ( status: 404, headers: Some({"content-type": ["application/json"], "content-length": ["27"], "server": ["uvicorn"], "date": ["Mon", "06 Dec 2021 09:32:24 GMT"]}), body: Present(27 bytes, application/json) ) > 09:32:25 [INFO] comparing to expected response: HTTP Response ( status: 404, headers: Some({}), body: Missing ) > *09:32:25 [INFO] Running provider state change handler 'UserA does not exist' for 'a request for UserA'* With --state-change-teardown: > $ ./rust/target/debug/pact_verifier_cli -d /home/mgeeves/dev/GitHub/mikegeeves/pact-foundation/pact-python/examples/pacts --loglevel info -p 8000 -s http://localhost:8000/_pact/provider_states --state-change-teardown > > Verifying a pact between UserServiceClient and UserService > *09:35:38 [INFO] Running provider state change handler 'UserA exists and is not an administrator' for 'a request for UserA'* > Given UserA exists and is not an administrator > 09:35:38 [INFO] Running provider verification for 'a request for UserA' > 09:35:38 [INFO] Sending request to provider at http://localhost:8000/ > 09:35:38 [INFO] Received response: HTTP Response ( status: 200, headers: Some({"content-type": ["application/json"], "date": ["Mon", "06 Dec 2021 09:35:38 GMT"], "server": ["uvicorn"], "content-length": ["134"]}), body: Present(134 bytes, application/json) ) > 09:35:38 [INFO] comparing to expected response: HTTP Response ( status: 200, headers: Some({}), body: Present(134 bytes) ) > *09:35:38 [INFO] Running provider state change handler 'UserA exists and is not an administrator' for 'a request for UserA'* > *09:35:38 [INFO] Running provider state change handler 'UserA does not exist' for 'a request for UserA'* > Given UserA does not exist > 09:35:38 [INFO] Running provider verification for 'a request for UserA' > 09:35:38 [INFO] Sending request to provider at http://localhost:8000/ > 09:35:38 [INFO] Received response: HTTP Response ( status: 404, headers: Some({"date": ["Mon", "06 Dec 2021 09:35:38 GMT"], "server": ["uvicorn"], "content-length": ["27"], "content-type": ["application/json"]}), body: Present(27 bytes, application/json) ) > 09:35:38 [INFO] comparing to expected response: HTTP Response ( status: 404, headers: Some({}), body: Missing ) > *09:35:38 [INFO] Running provider state change handler 'UserA does not exist' for 'a request for UserA'* After fix: > $ ./rust/target/debug/pact_verifier_cli -d /home/mgeeves/dev/GitHub/mikegeeves/pact-foundation/pact-python/examples/pacts --loglevel info -p 8000 -s http://localhost:8000/_pact/provider_states > > Verifying a pact between UserServiceClient and UserService > *11:43:17 [INFO] Running provider state change handler 'UserA exists and is not an administrator' for 'a request for UserA'* > Given UserA exists and is not an administrator > 11:43:17 [INFO] Running provider verification for 'a request for UserA' > 11:43:17 [INFO] Sending request to provider at http://localhost:8000/ > 11:43:17 [INFO] Received response: HTTP Response ( status: 200, headers: Some({"server": ["uvicorn"], "date": ["Mon", "06 Dec 2021 11:43:16 GMT"], "content-length": ["134"], "content-type": ["application/json"]}), body: Present(134 bytes, application/json) ) > 11:43:17 [INFO] comparing to expected response: HTTP Response ( status: 200, headers: Some({}), body: Present(134 bytes) ) > *11:43:17 [INFO] Running provider state change handler 'UserA does not exist' for 'a request for UserA'* > Given UserA does not exist > 11:43:17 [INFO] Running provider verification for 'a request for UserA' > 11:43:17 [INFO] Sending request to provider at http://localhost:8000/ > 11:43:17 [INFO] Received response: HTTP Response ( status: 404, headers: Some({"server": ["uvicorn"], "content-length": ["27"], "date": ["Mon", "06 Dec 2021 11:43:16 GMT"], "content-type": ["application/json"]}), body: Present(27 bytes, application/json) ) > 11:43:17 [INFO] comparing to expected response: HTTP Response ( status: 404, headers: Some({}), body: Missing )

Ahh tests fail

I'll have a look at it for you

:+1: it's not causing me any problems, I just noticed it when looking at state changes

Thanks for the fix!

I've merged it, but changed it to be non-async

:D Rust looks interesting, still on my Todo list to learn! Typing and traits are :open_mouth:

:facepalm: ah should have modified it to print "Running provider state [setup|teardown] change handler" or something, as well, I will leave that for another day because PR overhead :slightly_smiling_face: ..and meanwhile start reading the Rust book because even that tiny change took me way too long :smile:

has joined #pact-rust

has joined #pact-rust

@uglyog you OK if I release the latest FFI now that you merged that PR in, or was that on your list anyway?

Before we can release FFI, we need to release the mock server and verifier crates

But I can do those (wasn't planning on it)

yep, I assumed I?d need to follow the dependency chain. If you can do it though that?s awesome, thank you

@uglyog I?m finding a few tests don?t seem to work consistently across OS versions, and they all seem to be binary payload related. e.g. https://github.com/pact-foundation/pact-js/runs/4848121252?check_suite_focus=true#step:4:7668 https://github.com/pact-foundation/pact-js-core/runs/4812794228?check_suite_focus=true#step:4:361 (not the ubuntu build passes, but osx fails)

Those use the magic mime file type DB, which is GPL so we can't include it in the libs. It is also normally not available on Windows.

I thought that might be the case

I?m wondering how we deal with it cross platform

Should it not take the `content-type` header first, rather than sniff the payload?

i.e. if there is no `content-type` , fallback to the magic mime type detection?

That is assuming the content type header will always be correct.

I know. In my case, the tests have consistent setup and content types in the HTTP request, but the FFI is overriding what it detects and failing the build. What do you recommend ?

I?d say the majority of use cases will run builds on the same OS (so unlikely to get different responses)

There is an Apache project for doing this, but it is for the JVM. I was thinking of using their config files, but porting the implementation to Rust. They are Apache v2 licensed.

Raised an issue to track

:clap: JSON output

has joined #pact-rust

has joined #pact-rust

Do we want to move csv in pact-plugins to a new project e.g. pact-csv-plugin like we did for pact-protobuf-plugin?

has joined #pact-rust

That's a good idea. Then it will have it's own lifecycle

has joined #pact-rust

has joined #pact-rust

has joined #pact-rust

has joined #pact-rust

has joined #pact-rust

@tjones has left the channel

@tomas.sakinis has left the channel

Question RE: ffi. Are the builds supposed to miss libssl.1.1.so and libcrypto.1.1.so ?

What do you mean by "miss them"?

We publish shared libraries, so these if required would be expected in the target environment

P.s. have you slept? :scream:

Haha I did.

But I've been at this (it's bugging me) for a few hours.

I think this might be the wrong channel then, but there is a repo missing bundling them

If anyone has a link to a release with them included :pray:

libssl.1.1.so and libcrypto.1.1.so are the open-ssl libs

I'm assuming you're asking because something isn't working Lewis? What's the actual issue you're seeing?

It could be a build agent missing dependencies

Oh, I added it to https://github.com/pact-foundation/pact-stub-server/issues/47

I also believe this may not be rust specific. Because it came from someone else PR about FFI, I was a bit at sea, but finding my legs now. Sorry for all the noise. Just trying to solve this work Docker issue (that only happens in CI with pact verification)

Thanks, we appreciate both your efforts to solve it and your persistence