has joined #libpact_ffi-users

has joined #libpact_ffi-users

has joined #libpact_ffi-users

:wave:

:wave: Welcome!

Thanks :slightly_smiling_face:

Good idea, I was using bits of conversations in various places

I'm hoping this will be a good way to reduce re-discovery as people work with the ffi bindings

Mee too :slightly_smiling_face:

has joined #libpact_ffi-users

:wave:

Welcome!

For sure! Matt and Ron especially must be quite tired of pasting the same links over and over :D

haha! Yes

We have the libpact_ffi verifier working end to end for pact-js (not released yet)

Is there a "list" of current questions outstanding etc or just see what comes in?

I'm not aware of one - we're about to do the consumer bindings for pact-js

which I'm sure will generate questions

also maybe one outcome from having this channel might be some getting started documentation

The header files have quite a bit of documentation in them, but I didn't realise that to start with.

Nice I've been having a play with python but seem to be starting with trying to add to rust :thinking_face: Have you used the pactffi_string_delete function? On my to-do list to add in before going too far

I haven't, because we don't currently get any strings back from the ffi.

but yes, it seems important

this is the verifier bound to JS. Interesting bits might be: The mapper for the options to the CLI args that get passed in to the FFI binding: https://github.com/pact-foundation/pact-js-core/blob/master/src/verifier/arguments.ts

and the part that gets the result back from the verifier: https://github.com/pact-foundation/pact-js-core/blob/master/src/verifier/nativeVerifier.ts#L7

Also this might be directly useful - it downloads the libs for each arch: https://github.com/pact-foundation/pact-js-core/blob/master/script/download-ffi.sh

So, on the python side there is a python install_ffi_app function which will go and get them. From a DRY pov, it could make sense to have for example a sh script like that in pact-reference and then say from the python Makefile just grab and execute that instead. Here seems like a good place to start with asking other people from their respective languages as well if they think that would be a good idea :slightly_smiling_face:

What did you think of the idea I posted in #pact-rust about trying to just expose as much as possible including data types via an FFI call?

has joined #libpact_ffi-users

has joined #libpact_ffi-users

has joined #libpact_ffi-users

Oh, I haven't seen that! I'll check it out tomorrow - please feel free to hassle me if I don't report back

The experience from pact-js is that pact users can be behind all manner of corporate firewalls / proxies, so bundling with the library for installation through the package manager is a much nicer experience. Of course, that doesn't work for all ecosystems - go, for example, I think enforces that libraries are only go code.

Oh, I mean for the scripts to build from source rather than distribution if that's what you mean? As in when you do a "make package" it will currently call the python function to download the libs from pact-reference, I'm suggesting it could be: 1. Makefile downloads the script which downloads the libs from pact-reference, 2. Run that script to download libs from pact reference Rather than just: 1. Makefile runs the python (or other code) to download the libs from pact-reference Agreed about corp firewalls for end users

Currently bemusing myself a little as after the "can I help with contributing some python code" my first two steps have been ? Here's some rust code, could we do this so I don't have to write python ? What about we don't write that in python and user a shell script so I don't have to write that in python I can do python Dev, honest! :joy:

has joined #libpact_ffi-users

has joined #libpact_ffi-users

:wave:

thanks Tim - it was definitely time!

> Makefile downloads the script which downloads the libs from pact-reference, I'm nervous about doing "download this script then run it" in CI. I've been thinking about writing some automatic actions for pact-js to do things like making sure that some boilerplate files (eg CONTRIBUTING.md) are in sync across all the JS repos - perhaps something like that would work here? Also, I'm sure keeping boilerplate in sync across several repos must be a common problem with some nice solutions

In sync would probably better, I know what you mean about nervous running some "unknown" script (I'm assuming pact-reference repo would have a bit more oversight etc than in general, but still a fair point) I haven't looked into repo level sync :thinking_face: I was wondering about trying cookie cutter (python) to be able to re-apply a template to do something like that. I don't think any of the people I have worked with have fine across a good solution, given the state of many code bases :joy:

:thinking_face: thinking CI, you could lint style warn if some files are out of sync at least

Possibly this is where the monorepo answer comes in :)

[also re the nervous downloading and running, you could ofc have the expected checksum etc of the file to make sure it doesn't change unexpectedly... But maybe at that point for something relatively simple it is back to more comfortable to just maintain when needed :thinking_face:]

> Possibly this is where the monorepo answer comes in :slightly_smiling_face: Yeah. JS doesn't have any really nice solutions for monorepo - there's a pretty well liked tool called lerna, but I believe that requires yarn, and they've been doing some weirdly opinionated things that break dependency management because they disagree with the way npm works. Which is... fine academically, but not helpful in practice.

"Creating a default community health file - GitHub Docs" https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/creating-a-default-community-health-file this looks promising for the original use case you mentioned, I haven't tried it yet to see what it does exactly, if it uses then only on creation of automagically has them there, I'm sure GitHub could display then when viewing the repo if they aren't actually committed to the repo itself but I'm not sure how it could work when you pull it, and you probably want it visible in the actual repo

At risk of going OT from FFI already :)

Oh, that's awesome!

Thanks

Has anyone got the ffi libs working on windows yet?

How did you do it?

oh wait! I did it!

I?m _assuming_ one of the Pact .NET people did. It?s fair to assume most .NET people still use Windows, right?

I think this might actually pass

wait, this isn't a PM with matt. Apologies everyone!

For those playing along at home, you need `.dll` not `.dll.lib`. From the error messages, I suspect that `.dll.lib` is for 32 bit? I am not sure.

That seems likely

:laughing:

it?s best everybody sees how the sausage is made Tim

Any thoughts? As with the other discussion on the .sh files, no point in progressing if it's considered a bad idea, I'm happy either way but especially since I've not actually "contributed" anything yet I'm a little wary of doing too much without input on good/bad direction :slightly_smiling_face: I didn't actually get the data type part going yet (although maybe that's not so important), works pulling out the args, defaults [e.g. http], allowed values [e.g. log]. Although a different route could be that since clap supports pulling in the config from a yaml, maybe that could be a better starting point than deconstructing afterwards :thinking_face:

Largely it looks like a good idea! I like the idea that it will possibly simplify / genericise implementation. I'm not sure it would work for all cases (we can't easily, for example, generate the typescript types for it from the binary - although maybe we could make tooling that could)

I think there might be some work on getting the ffi verifier going in Python already - I think I remember seeing @elliottmurray talking about it some time

has joined #libpact_ffi-users

> a little wary of doing too much without input on good/bad direction I'd say anything that makes it easier to get value into user's hands is a good thing. The question for me would be how much easier would it be with the proposed interface vs the current one

In the case of the verifier, if you look at the mapping code I linked earlier, it's not actually a lot of work to map it without helpers. However, the work that we did there will have to be re-implemented in the other languages each time. Of course, if we had a generic interface, a mapping is still necessary, but it might be simpler? I don't know.

Do you have a specific thing you want to contribute, or just "I'd like to help out"?

(I probably have different guidance depending on the answer there)

Of course, as with any open source project, the main answer is "work on something you'd enjoy working on" and "yes please, we'd love extra contributors"

Thanks for replies :slightly_smiling_face: So I'm looking at python mostly [most comfortable language of choice] - have already briefly spoken to Elliott who suggested taking a look at the FFI stuff. I just started getting distracted with Rust early on :smile: My area of expertise is generally going off on tangents while looking to improve CI/CD, processes etc. Largely happy to help with whatever, long time in a closed corp environment, seemed like time to try and "give something back". The original purpose right now was because I wanted to do event testing of some AWS code I'm working on and it wasn't possible in python yet, but I think Elliott has recently made progress with that against the previous spec implementation. Yeah, generating the types was going to be a next [in a few steps time] step to look at, I'm not quite sure how to nicely do that on the python side yet either. I'm thinking there might not be an easy way to create them directly but it could always be a step when retrieving the FFI libs themselves via script or code during packaging to generate *something*. I like things that write themselves, but opinions vary on keeping it pure vs kind of a hack, hence question of does anyone else like the concept :slightly_smiling_face: For example [very quick google search, could be a non starter], https://github.com/cwacek/python-jsonschema-objects this looks like it could work to get a bit of JSON [which would come from FFI, maybe with a bit of mangling] that could be grabbed at package time, and then use that for creating your object with typing For the CLI part, since it's just "dumbly" calling the binary with the args more or less, it looks fairly simple for the wrapper, but there's still the actual verifier to look at directly which will probably be tricker!

For sure not much work to map it, it's the ongoing has anyone noticed that something has changed and now that needs updating across the various languages, as with the contributor.md example where you have the...and why is it ever so slightly different over here that I'm thinking about

Ah, or like this for typescript [again, quick google search, may be no good] https://quicktype.io/typescript - from a maintainer pov I think I would be more comfortable with a flow of download an updated external lib and then be able to see in an e.g. generated json file in the repo that something has changed from last time, than hoping my tests cover sufficiently a potentially fragile link to a lib and having to figure out why it now segfaults

On Widows, `.dll.lib` is a static library that contains all the code to load the shared library `.dll`

With languages like C/C++ and .Net, you probably need both

hmm... it worked ok in CI with only .dll

maybe the tests aren't fully functioned

(the node ffi bindings pretend it's C)

Node can deal with just the `dll`

Ok so, I've made a couple more changes to the FFI method to pull out the Rust CLI args: https://github.com/mikegeeves/pact-reference/pull/1/files#diff-0683cbee93e01f96b27383c0954421fc5be638947d54311f880ba9b84ba2cb61 - that seems to be complete enough for me to construct the CLI args on the python side (the only missing bit is types to identify an int or str, I didn't see how to cleanly pull out something from the validator but I think that's ok to skip for now). Does that look helpful for use elsewhere? I'll wait a bit then hit the PR button :slightly_smiling_face: > $ pact-verifier --help > Usage: pact-verifier [OPTIONS] > > Options: > --enable-pending Enables Pending Pacts > --disable-ssl-verification Disables validation of SSL certificates > --publish Enables publishing of verification results > back to the Pact Broker. Requires the > broker-url and provider-version parameters. > > <snip> > --scheme [http|https] Provider URI scheme (defaults to http) > -p, --port TEXT Provider port (defaults to protocol default > <snip>

The Rust change would largely be redundant if using clap from yml config which could be shared around instead, but that doesn't look like it supports validators. Types are hard :slightly_smiling_face:

has joined #libpact_ffi-users

*tsk* *tsk*

Nah .Net just needed the `.dll` not the `.lib` as well

You bet your bottom dollar we do :smile:

Ah I wrote basically an identical thing to this script here... https://github.com/pact-foundation/pact-net/blob/feature/4.0.0/build/download-native-libs.sh

And we also bundle those inside the NuGet packages that PactNet generates, then it'll extract the appropriate one for your arch/OS when you install the dependency

I'm afraid I don't (yet) read rust, so I can't tell very easily. If this is what we talked about earlier, yes it sounds useful.

It is yep. That's ok I don't write rust as such either :thinking_face:

Hitting the big red button after adding a test

Memory management and pointers etc scare me :open_mouth:

Ohh, I forgot envs, but no more time right now :thinking_face:

[added :D]

Following on from half a conversation with @pact544 about output from the FFI lib, could something like slog-json be useful, rather than stdout style logging from fern? Something structured could then mean less mangling on the python/net/js etc side, which can be quite brittle if doing anything other than passing straight through. There seems to be some JSON output as well sometimes but not quite sure exactly when/why/how, I need to look through the code. Not sure if that's all in progress, already considered etc, any thoughts @uglyog / anyone else on how they are planning on working with/using the output :slightly_smiling_face:

:man-shrugging: I don't have any opinion either way. What ever works to make it easier for users to be able to provide information to diagnose issues.

There's also this, which I'm planning to bring the rust library in line with: https://github.com/pact-foundation/pact-specification#logging-in-a-pact-library

Tim: I couldn't see anything by that other than "tldr: make sure logging levels are correct" (which absolutely makes sense, I think info when the pact test fails but not the lib/usage is an important distinction to clarify, for example :+1:)

Was that it or did I miss something? :slightly_smiling_face:

Tim?s put together some notes about what we *should* be logging at each level, and the purpose of log levels for the framework

if everyone agrees on the terminology and meaning of a `debug` log, then we can more confidently create useful end-to-end experiences (i.e. have the client and rust libraries use the same meanings for each of the log levels,)

but yes, basically those kinds of distinctions is the point

it?s separate from fixing the logging itself, so that we can more usefully present them to users

Yep. I was mentioning it as a side point, since we're talking about logging and making the logs available to different frameworks

btw, what we're planning to do in pact js is to defer all logging to rust.

this is fine, because in js land people expect logs on standard out

it won't work for ecosystems like .NET though.

and structured output lets us do lots of nice QoL things - like "hey, you're missing state change definitions for these states, here's a template you can paste into your code"

I'm not sure of the value of structures log output, I haven't thought too much but that's a good example

Structured verifier output though would be preferable, separate to structured logs

I like having a consistent way to show verification results - that will make docs much easier ("here's how to interpret verification failures")

yep

Yeah that's what I was thinking, around the filtering. If you've got the structured log output it's then much easier (at least less brittle) to for example filter out the content relevent to verification logs. Especially if that's going to be info level rather than error for example (I think info does make the most sense) If it's a structured log you can then use the language native functionality to filter and say stream the info logs of type verification out to a file and error logs to stdout and so on, as well as being able to have a more language consistent user experience if it 'looks like python logs" Architect hat on here, I can see a few user cases where it could be beneficial, at least imo, but if it wouldn't be seen as valuable across various languages then it's over engineering

:100: for consistent terminology etc, principle of least surprise

? I would definitely go for Tim's guidelines on making the log levels consistent ? If a structured log output is desired it would be effective looking at both together I think, e.g. if something was an ERROR and now it's an INFO, it's a good time to make sure you have e.g. a way to distinguish it from "just letting you know" (easier than doing later)

Yeah I think the main thing I've found with the consumer logs we have is that they're very Rust-like. There's lots of `dbg!` style output where it'll say things like `header: Some(Header::ContentType("application/json"))`. That's kinda fine for me because I know Rust, but to someone who primarily does C# that's all a bit weird. Those aren't the types of things you're expecting to see to help you work out why your test is failing. Its good for debugging the Rust code itself, but I'd prefer a more human-readable style to display to users in the general case, and perhaps a flag or log level which enables the very Rust-specific output for cases where we think it's a genuine bug in Pact rather than a user's test failing properly.

Especially if people have only just got the hang of what ruby output looks like :grinning:

that should be `trace` based on Tim?s output

trace == for maintainers

debug == for users to be able to debug the problem

but probably the use of `dbg!` is not good anyway

Hopefully the bug in pact should be covered by error with failing pacts as info, but there's going to be quite a bit in info

Nod

I think it's probably either using `{:?}` or just deriving Debug/Display and logging the object itself. You get a Rust-specific representation

I've not actually implemented structured logs myself as such btw, but consuming AWS CloudWatch logs.. it'smuch nicer being able to filter and work with than just a stream of text, from my experience with them at least

I suppose the flip side of "hiding away" that is a rust log is it could make it slightly more opaque for debugging rust problems, if the end user logs are formatted differently depending on which language they're wrapped in? Possible downside but I wouldn't consider it a huge one

Last night I started on a PR to fix up the rust logs

I don't know rust though

so probably it's not correct

> for debugging rust problems This is the purpose of the logging guidelines. If the log levels are used consistently across frameworks, we can pass the log level between frameworks and not be concerned about exposing the "wrong" thing. `TRACE` is what we'd want to use for "super detailed, you have to know the framework source"

I'll review that, but I'm going to warn you now that I work on the principle: info is for the user, debug is for me and trace for when you need to know what is going on in detail. I'm not going to trawl through trace level logging to try diagnose an issue a user is having.

It's not actually ready for review yet (I'm not even sure it compiles)

> I work on the principle: info is for the user, debug is for me This is why I asked about the guidelines before publishing them :confused: I think it's very useful to have a distinction between user's debugging of their own tests and maintainers debugging the framework.

https://pact-foundation.slack.com/archives/G9VHV9VJ9/p1624921762104900?thread_ts=1624876877.103800&cid=G9VHV9VJ9 :wink:

I'm happy to accept some logging changes, but there are some debug level statements that are essential to stay at that level

I would add, I think you could hopefully address both sides with a structured log approach :thinking_face: Filtering the "kind" for example

has joined #libpact_ffi-users

@uglyog I think your need to have a debug mode that isn't `trace` is a good one, but I'm not sure how to support it while also having a good debug mode for users. What about having an extra environment variable (eg `PACT_FRAMEWORK_DEBUG` that enabled extra debug logging?

One problem in rust is that it seems to pick up the loggers from dependencies too - the final pass in the logging PR would have to be to match those to the guidelines as well.

I really would like a common set of guidelines for all frameworks, so if the proposed guideline doesn't work for you, let's find one that does.

Rust logging doesn't let you filter dependencies (like you can on JVM). I'm sure eventually there will be support for it, but for now we get all the async and HTTP framework logs as well.

hm ok

maybe we need a different way to control the logging for rust

`PACT_LOG_LEVEL` or something

@matt.fellows did you say you hit a way to filter the logs in rust? I thought you did, but I can't find it in a search

:thumbsdown:

I'm going to say structured logs again :smile: but I have no idea complexity involved to set that up in rust / the impact it could have elsewhere :thinking_face: (happy to look when there's next some time for a tangent but skill level might not be quite there) If you could add in tags against the types of errors you were interested in then worst case it's pretty straightforward to filter out those that don't have it when you're consuming

Structured logs could probably mean you can then filter out unknown packages i.e. dependencies if needed, which would be a crude way to achieve the above

yeah that's what I'm thinking, https://substrate.dev/rustdocs/latest/slog/struct.Filter.html as far as I understand this, if you have your "normal" rust drain [outputting say to stdout/stderr], you can then take that drain and wrap it with a filter on each record to then e.g. output to your ffi log buffer?

@mike.geeves064 possibly! Although, in pact-js, we don't want an FFI log buffer. pact-js wants Rust to log to stdout. So, I think the requirements are: ? Able to be rolled into a buffer for .net (and presumably others) ? Able to be logged to stdout for js (and presumably others) ? Not to have users needing to wade through logs that concern the implementation when debugging tests ? Not to have Ron / maintainers needing to wade through other package's trace logs when debugging pact. Have I got that last point right, @uglyog?

Awesome! @mike.geeves064: Would this be something you're interested to take a look at? I'll wade in if you're not interested, but don't want to step on your toes if you had an approach in mind and were excited about looking into it

I am always interested at playing with new things and excited about looking into them, this is the cause of many of my problems :joy: Where does it fit with priorities and timelines? If you're also interested and excited and it's blocking right now then it's probably best to wade in, if it's more on the chore side but needs doing to meet the log consistency goal I can take a look when I've finished the first bit of adding in tests for the python CLI wrapper, at least to get an initial poc of what I was thinking to see if it looks like a sensible direction or not

I?m not keen to release pact-js backed by rust without sorting out the logging, but it?s not urgent- we have plenty to get on with and the only thing this blocks is the release

Yeah likewise. Without really good logging support I'm not keen on releasing PactNet either. If tests fail then you need really good info on why

has joined #libpact_ffi-users

has joined #libpact_ffi-users

Getting closer to looking at logging, still a while off so let me know if it's needed too urgently to wait any longer :slightly_smiling_face: I've finished the next steps on the python side, trying to use the generic verifier arg functionality. It's working ok along with a couple of tests for the CLI pact-verifier and first steps of the method via code. Could do with some input on approach before taking it much further though. Currently it's fairly light on tests as I've offloaded all the logic of what args are needed onto the requirements of the FFI call to avoid duplication, which seems to work well. Need to see what else would actually be of value to include. What I've been wrangling with today is what to then do that works nicely on the code (i.e. not CLI) side. There are a few options I've been experimenting with, attempting to generate classes via different methods based on the FFI call, I've tried: ? via a library "python_jsonschema_objects" which makes the class from some JSON ? using the dataclasses "make_dataclass" ? [now removed] attempting to use pickle/dill/cloudpickle to save a generated class via those two and other approaches, hoping to then be able to generate and load "later" ? finally making some source code For comparison, very incomplete but functional alternatives are in here: https://github.com/mikegeeves/pact-python/pull/1/files#diff-323d43ee17cc3973c5557456838b3406710ad8f9d395fc3117acbe24b5ec9058 with the source code generated by that option currently here: https://github.com/mikegeeves/pact-python/pull/1/files#diff-cc76c1ff6a766e7d39a30eb0af4b35ec4d003594940b09bc295668426724a749 Generating some python source code (literally just containing the class) seems kind of clunky, but has been the only realistic way I've been able to then have something that will give type hints to users of the contents, since the other approaches are all generated at run time (I was hoping a serialised pickle would work round this, but seems not as it's still loaded at run time only). The idea being when downloading and packaging up the latest lib binaries, it could just generate then, meaning the maintainer would see if anything significantly changed as well. @tjones interested to hear your thoughts on that as an approach, we briefly discussed when first looking at it @elliottmurray could still do with some general input on if the approach/structure looks ok so far or any significant areas to change: https://github.com/mikegeeves/pact-python/pull/1/files assuming not I'll clean up what's in there, subject to opinions on code generating code which is then packaged up etc

Starting to try and read up on the logging a little: ? as a first step I'm looking to swap out the println calls for logging, which I'm assuming should all end up as INFO (message to the user about their pacts) ? still output to stdout ? as well as ideally a stream and temporary file ? any of those print->info entries should be distinguishable from anything else that would try to log as INFO Is that in line with needs/expectations or anything misunderstood etc? First glance I can't see a stream to buffer with slog

Do you mean in python or in the ffi?

If you're asking about the python logging, this is probably not the right channel

I'm not 100% sure I'm following here - let me see if I've understood: ? You're looking at generating types from the ffi ? This means that you could see at compile time if the interface of the ffi has broken (at least in terms of call signatures) is that right?

FFI

Yes that's largely it. Can do dynamically at run time but then you lose IDE hints for users which would be a rubbish experience

In theory if it's say a new flag added, the maintainer wouldn't need to do anything else at all, just commit, if something is different, "politely discuss" with the Rust maintainer why backwards compatibility has been broken

What functionality if looking at swapping print for logging of some sorts would be desired across the language bases

In the FFI logs are already going to the logger

do you mean the test output?

I don't think the test output should go through a logger

You can see the logs that are already logged in here: https://github.com/pact-foundation/pact-reference/tree/fix/cleanup-log

I think test output is a different beast, because if it goes through a logger it would be harder to parse it. For test output, I think some kind of structured response is probably best (the consumer tests already have this, I believe)

:thinking_face:

That was where the suggestion of structured logging comes in, because it's then simple to pull out the message part

I may have misunderstood what you meant by: > `Info`: You probably want to know this every time you run pact, and if tests are failing here is an explanation

> What functionality if looking at swapping print for logging of some sorts would be desired across the language bases There's a comment on that above somewhere, I'm only partly here so I can't link it right now

So you're not thinking include that in the logs then?

For test output, we don't just want the "messages"

because it's like "given this state, and this request, this response was verified"

the problem with the logs is that they're super verbose right now

Might be worth more of a conversation when you / someone is more here :slightly_smiling_face: I think I've possibly got a completely different understanding currently

nod

timezones are hard :slightly_smiling_face:

eg this

This doesn't fit the logging guidelines we're moving towards, but the problem is that we can't control logging for Rust libs easily. We get their debugs too

so probably we need our own logger

so it's about changing the currently logged things

there's already a logger, but the logger logs to stdout. .NET (I think?) doesn't want stdout logs. It wants to get the logs and do something with them

(probably print them itself)

so there, structured logs would work nicely

but it's not changing the printlns, because there aren't any

(I am thinking which is slow :slightly_smiling_face: )

hopefully that makes some kind of sense. I'll write more clearly when I'm not disappearing

I'll be back later and/or tomorrow

hope you're well!

sure

would a quick video call work better than typing long notes?

(whenever, not right now)

sure

thinking of how time consuming it can be trying to give detail in a message

I think I'm possibly heading in a different direction on some things but I'm not sure they're necessarily different :slightly_smiling_face:

when suits? or alternatively just ping when I'm online and you have time :slightly_smiling_face:

I definitely have some wires crossed as I was thinking more around rolling into a single filterable source but still with stdout, possibly around confusing build tests with pact tests

anyway, talk another time then! :slightly_smiling_face:

> when suits? I'll get back to you on this. Others might be interested too, idk

I'll probably pause for a bit then, no point going on a tangent if it's not of value

:thinking_face: normally I'd go through on a miro board (for example) and just run through a bit of a flow of the different types of information, where they go and where people would like them to go / what they want to do with it

I've made a quick board as a starting point: https://miro.com/app/board/o9J_lxta2uI=/ - I'd like to try and understand when person of type x is doing y they would like info from a to go to b and c to go to d etc

"so that they can..."

tbc :slightly_smiling_face:

has joined #libpact_ffi-users

Has anyone had trouble with `--disable-ssl-verification` not disabling ssl verification? I'm not sure if we're invoking it incorrectly here: https://github.com/pact-foundation/pact-js/issues/736#issuecomment-919147536

I?ll take a look today Tim

Re the various issues Beth's created on 'Set "enable pending" to true by default', that's a good example of where I would see it being beneficial having that single source of info with the method I created on the Rust side (retrieving the args and their defaults etc), so all the updating work would then involve is use the new Rust FFI lib version. Could still do with some input if anyone else thinks it's remotely a good idea, since it would be probably a bad idea if just Python had that approach, nowhere else (and I still don't know if anyone likes that approach on the Python side either :thinking_face: )

I'm still to catch up on that work, but how would that solve it?

The clients still need to update the mapping right?

reduction of effort required, it should then just be version bump to use the new lib, and it will then pull in the defaults from there

I see

It's more than just arg mapping but also defaults

yeah, so for the python one, it pulls in the --long-name -l [short name], ENV to use if available, DEBUG|INFO etc for options and default e.g. http for scheme, and I'm using that to automatically "populate" the args to call by cli to then use them

and more recently, looking at generating some argument class to then be able to have some form of type hinting

hence it's very much a, i think this could be an interesting approach but i could totally understand dislike as an approach :slightly_smiling_face:

generating a class with the values in for example, I'm of two minds about, because "print out" something to make code kind of seems horrible but it actually works well :smile:

(Just with kids rn but I'm digesting)

:+1: np, focus on kids! I'm just heading off for a while anyway

Hey Mike - so I have run through the code at a very high level and was 'digesting' this mentally. I've also just not had the headspace this last month or so for Pact generally so apologies - wasn't ghosting you!

While I do really like some of the suggestions - creates some nice pass thru and would in theory make all sdk's more aligned it also makes me a bit nervous when you go down this 'auto-generate' route. That's where I'm at really and haven't moved beyond that yet (well still trying to understand FFI tbh!)

Previously with Ruby there would occasionally be an issue with having to update an api it was often pretty easy to add it to click and change the code. Not saying this is optimal just wasn't my biggest pain point. So it's a trade off with some 'magic' versus a little more maintenance I guess?

:100: it's very much a preference of approach, I like the idea of making the codebase as a whole much more DRY (across multiple languages) and overall reducing the amount of choice you need, it is adding in some magic. I'm totally with you on a bit nervous about auto-generated (imo I think overall it's ok, but it's not my codebase so I'm happy to keep in line) :slightly_smiling_face: In a "real world" situation, I'd generally try and have a call with a group to go through pros and cons of adding magic to determine if it's desirable to continue, bin the whole idea, continue if some concerns can be sufficiently addressed, or come to an agreement on the level/scope to implement something and where the line is Not sure the best way here? :thinking_face: Fine with shelving if that's the preference, but then need some input on what to do instead No problem about time, headspace is always tricky :slightly_smiling_face:

Part of the challenge of the auto-generation approach is that it's hard to come up with a good solution that produces idiomatic code in all the languages and frameworks (have a look at the mess of inconsistency that is autogenerated swagger clients + servers for an example). I really like the idea of adding instrumentation to allow consumers of the ffi to "inspect" it, but I think it will be useful in different ways. For example, in pact-js, the CLI args are defined here: https://github.com/pact-foundation/pact-js-core/blob/master/src/verifier/arguments.ts - I don't think there's a lot of value in autogenerating this code for JS (even if it were possible), because the calling code would have to be updated anyway - even if we exposed the autogenerated code right to the boundary of pact-js, we still have to update examples, documentation, etc. On the other hand, manually maintaining this code is not especially onerous. We do occasionally have problems where the wrong argument is used (or arguments are removed / changed), so I see the arg-exposing functions you added being most useful in tests in pact-js - I'd love to have this implemented, and I think it's a clear improvement.

The other thing that could be autogenerated is this type, which needs to match the declared functions: https://github.com/pact-foundation/pact-js-core/blob/master/src/ffi/verifier.ts A risk is that this type is wrong and we don't pick it up during tests. If we autogenerated it, it would solve that problem. Perhaps this can be done automatically by parsing the .h file, or exported during the build of the ffi. That would be cool. But, on the other hand, maintaining this file is not a significant amount of work - and anything that breaks the definitions in here should technically be a breaking semver change in the ffi.

My summary from a pact-js perspective is: ? I think autogenerating the types would let us reduce some risks and may make maintenance easier (of course, it may make it harder, especially if the autogenerator required maintenance) ? However, I don't think those risks are especially large, and the maintenance gain seems small, so I'm unlikely to work on it as a matter of priority ? If someone else wanted to work on it, I'd welcome it

(I love how FastAPI with pydantic actually nicely gives you the possibility of having validation "defined" which goes into your Swagger instead of the car crash of half assed Java annotations I dealt with in the past, but that's an aside :smile: )

It does bother me a bit that we're a contract testing framework, but don't have a clear way to test the contract between the the boundary of either the rust or the ruby core.

:joy:

I was thinking earlier actually, I'm sure it was in some Pact blog/tutorial I read about pitfalls and what you don't want to do is just duplicate the same thing in your Pact tests, there's no point in having identical tests of exactly the same thing in multiple places

> I love how FastAPI with pydantic Right! So, this is what I meant by "a good solution that produces idiomatic approaches" - if we *have* some tooling for autogenerating, I don't think we can do a one size fits all

appropriate tests in the appropriate place

:thinking_face: I get your point, but I'm not sure it would be a "can't", it is essentially an interface so as long as the interface provides what is needed you can, but I do agree about maybe it doesn't add value

My summary from a pact-maintainer perspective would be: ? I think this is interesting but low priority for pact-js, because of the tradeoff of small amount of value for us, but probably medium-to-large time investment ? I think it might be more valuable to other pact implementations, depending on their idioms and maintenance challenges ? If it is more valuable to other pact implementations, I'm not going to argue against it

The tests area I think is interesting, because I would question the value around testing what does it do when you call it with arg x and y but not z, and having business logic in the JS/Python etc to deal with what combinations of arguments you need.. because this is covered on the Rust side, and if the Rust side can [and should, and should have tests] making sure it is called correctly, I'm not sure you add value on the calling implementation essentially doubling up on that, you're adding in a lot of duplicate code/functionality/tests [there's for sure a line somewhere, obviously you want to have some tests to make sure it works etc, but maybe you don't need to test so much]

Yes, that's very true. In pact-js, we're moving away from heavy validation of the arguments before passing to the binary, because otherwise it requires updates on both sides when they change. However, this means that the "contract" is that the binary produces good error messages appropriately

which goes onto our other conversation around logging/output :smile:

I think the duplication of validation discussion is unrelated to the autogeneration of a calling interface, though

> which goes onto our other conversation around logging/output Yes, exactly.

bedtime here - but if I had something to autogenerate the types for the JS side of the FFI boundary I would absolutely use it. I think maintenance tooling can save time or attention - and in this case it would save about 60 minutes of setup time, and no additional attention

(for a better elaboration on the attention idea - here's an excellent talk that was here in Melbourne a few years ago: https://www.youtube.com/watch?v=6_q3kQUNpLA )

:+1: thanks for the input, I'm having a look through there to see what I've missed/not come to yet

trying to figure out what else is there that would be problematic :thinking_face:

Apologies, it looks like that talk is from Sydney, not Melbourne. Unacceptable. Anyway, the talk is the same one, and it's still great.

and some of the why :thinking_face: [for example deprecated could be useful to try and figure out how to put that in]

:joy:

I'll have a watch now

I don't think that verifier.js would be that hard to generate programatically [although I don't do JS, but then I don't do Rust either :smile: ] The value thing is really hard, I think the pets vs cattle analogy might work here also, I liked moving away from even low maintenance servers that were manually rebuilt, to just something you can wipe and reproduce with confidence :thinking_face:

I wrote pact-js's custom arg mapper (linked above) precisely to allow arbitrary handling of arguments - we have convenience mappers for common cases (including "just print a warning if someone uses this"), but can also provide arbitrary functions, because sometimes we will want to do something really user friendly that is easy to express in a few lines of code

nod

> I don't think that verifier.js would be that hard to generate programatically It absolutely would be easy to generate. But, it would lose the ability to be very human if we did that.

I need to look more at the things using it aside from the CLI directly

for python as well that is it works great for CLI just passing through args, but the generated objects and what to do with them is a lot more complicated

It's not hard to generate, but it's also not hard to manually maintain

for sure

I'm still on the fence about the whole idea in a way, because even if the CLI part is way improved... if you still have to do basically the same thing to call it via a method anyway, I'm not completely sure it's better overall because it's following two different approaches -> also trying to figure out what else is missing to see if it could work for both

In pact-js, I'm keen to find things that make things simpler for us. For example - @matt.fellows and I just lost two days of pact maintenance effort to: ? `npm link` doesn't always do the right thing with npm dependencies, and we use it to trial the existing examples against the current build ? For some reason, the musl version of the neon rust bindings for js doesn't build on node 16 (deep into mountain yak territory)

ouch

yeah I saw the abandon node 16 for now

neither of those things are specifically to do with things that provide value to pact users (other than "pact currently uses them to test / build")

So, as a maintainer, I'm mostly for anything that makes it easier to get value into user's hands. My recent experience is that more complexity is generally not the answer.

agreed on that one

neon was great for allowing us to easily spike a rust-backed pact-js and get it out into user's hands. But it made the build significantly more complex (and necessitated including rust directly in pact-js), which has in the longer term meant it's harder to get value out the door

The moment in that talk that talks about attention is around the 22 minute mark

```Simple is better than complex. Complex is better than complicated.``` :slightly_smiling_face:

her point is something like "saving time is one thing, but this thing that doesn't save me time does save me attention, and that is better" (wildly paraphrasing from memory)

yeah that makes sense

Aaanyway, I really should get to bed. I'm supposed to be awake again in 6 hours

good chat!

I like automation, but not if it's obscure as a result

Right!

I'd like to automate the things that are regularly costing us time or attention. The typings to the ffi mostly cost us setup time and attention

so if everyone thinks too obscure, bad idea :slightly_smiling_face: no objection there I would think hopefully, if you can make it generate things itself that as you mentioned wouldn't probably take a hugely shorter time to make a branch, update a version number and run a script to generate than it would to go through release notes and pull out variables, but the attention definitely does apply there

An example of a significant win there is when @bethskurrie automated the version bump of the ruby standalone so that pact-js gets a PR every time a new release is made. It is SO GOOD

nod

I'm going to stop replying for now so you go to sleep :joy:

Fair :joy:

[one last one: there is still the balance with some, of if it is making new dtos etc you would possibly want to at least "code review" the changes before building and shipping, maybe]

anyway, night :slightly_smiling_face:

Also, I like that your message describing the auto version bump pretty much crossed with mine describing the same thing

with pact-js, we chose to review manually rather than automatically merge and release

which means the code review is a bit there

It would be excellent to get the same thing happening with the FFI

currently that's entirely manual

anyway, yes. Goodnight!

:joy: :wave:

:thinking_face: I like to hunt yaks but I think I may accidentally farm a few thousand :thinking_face:

Tim and I are professional yak shearers

(I suppose Sheep, given Australia)

(I like that video a lot, it also makes me happy that a woman can now give a talk on a subject like that, starting with "omg tangents what am I even doing" and not get shot down as "that's just because you're a woman so you can't be a good developer" progress! also I would not have the confidence to stand up in front of people and give a talk in my socks :joy: much respect :smile:)

I think I watch it about once every 6 months.

[:thinking_face: still not completely sure where to go with this especially on the python side, but while my model builds, I had a "quick" look at the identifying available functions from the library: ? looks like a pain trying to introspect within rust to pull it out via macros etc ? looking at the lib itself, there are some packages e.g. ffi-generate using clang to pull out, or swig which can generate the stubs and objects for just about everything other than JS :joy: but it all looks quite complicated ? so finally trying your suggestion of using the header itself [I did start with that one, found cbindgen, started looking at adding it, found it was already there, then saw the output and went elsewhere for a while :smile:), the ones setup in the build already are quite large and would be a pain to parse, so had a look at reducing that, and I can get cbindgen to produce a much smaller .h file with just the functions all nicely on one line, so with a quick grep it ends up as: > $ cat include/pact_stripped.h |grep -v -e "^$" -e struct | grep '(' > const char *pactffi_version(void); > void pactffi_init(const char *log_env_var); > void pactffi_init_with_log_level(const char *level); > void pactffi_log_message(const char *source, const char *log_level, const char *message); > int pactffi_get_error_message(char *buffer, int length); > int pactffi_log_to_stdout(enum LevelFilter level_filter); > int pactffi_log_to_stderr(enum LevelFilter level_filter); > int pactffi_log_to_file(const char *file_name, enum LevelFilter level_filter); > int pactffi_log_to_buffer(enum LevelFilter level_filter); > void pactffi_logger_init(void); > int pactffi_logger_attach_sink(const char *sink_specifier, enum LevelFilter level_filter); > int pactffi_logger_apply(void); > const char *pactffi_fetch_log_buffer(const char *log_id); > void pactffi_string_delete(char *string); > int32_t pactffi_create_mock_server(const char *pact_str, const char *addr_str, bool tls); > char *pactffi_get_tls_ca_certificate(void); > bool pactffi_mock_server_matched(int32_t mock_server_port); > char *pactffi_mock_server_mismatches(int32_t mock_server_port); > bool pactffi_cleanup_mock_server(int32_t mock_server_port); > int32_t pactffi_write_pact_file(int32_t mock_server_port, const char *directory, bool overwrite); > const char *pactffi_mock_server_logs(int32_t mock_server_port); > bool pactffi_check_regex(const char *regex, const char *example); > void pactffi_free_string(char *s); > int32_t pactffi_verify(const char *args); > const char *pactffi_verifier_cli_args(void); that I think that would be pretty straightforward to read in on the JS/python etc side and token match to produce the info for those types, it might even go in as-is with how the python one works .... you meant that, right? :slightly_smiling_face: ]

> even if we exposed the autogenerated code right to the boundary of pact-js, we still have to update examples, documentation, etc. On the other hand, manually maintaining this code is not especially onerous. With the CLI example, why would there be any difference between the CLI provided by python, or the one provided by JS, .net, and so on? Unless I've missed something, I can't see why you would have any behaviour differences at all, you're wrapping up the functionality exposed by the shared lib, so if you end up with say python cli being `pact-verifier --some-user` but for the JS cli it is `pact-verifier --someUser` that seems like a very confusing direction, and I don't think that happens anywhere?

-> why is there documentation and examples to update for each language anyway? vs a single source of the latest set of examples applicable to that version of the underlying library

> that I think that would be pretty straightforward to read in on the JS/python etc side and token match to produce the info for those types, it might even go in as-is with how the python one works My point is, yes we could do this ,but it would be a fair amount of engineering effort and moving parts (which means more maintenance effort in the future) to achieve something that is not currently difficult or onerous to do by hand, except for the first time.

(had a brief discussion with Matt around docs on this)

> -> why is there documentation and examples to update for each language anyway? We have no spec for the implementation features (eg, matchers that are composed of other matchers, developer productivity helpers etc). Having something like that would be amazing.

there's a lot of e.g. Pact docs have info on matchers, then each language then goes onto explain in the readme some similar but slightly different explanation, it's making a lot of work for everyone :smile:

:thinking_face: as in some languages can do matchers of matchers but others can't?

Yes, a single source of documentation on "this is how it works" with eg tabs for "show me this in each language" would be AMAZING

nod nod

I came across: https://docusaurus.io/docs/markdown-features/code-blocks#multi-language-support-code-blocks when I was having a look the other day

sorry yes, ofc there are differences in the implementation of an example, syntax between languages, but that's just "translation" of the same thing, rather than one having an example while the other doesn't

Even ignoring the obvious benefits for users (and not needing to maintain multiple instances of the same documentation), the benefit of "oh! This feature isn't available in that implementation" would be super super great

Largely the reason we don't have this is "no one has had the time yet"

:smile:

I would wholeheartedly support any effort to do it

I'm up for docs, although a little wary of giving the impression I half start a dozen things and finish nothing :smile:

That's not (currently) my impression

that's good at least :smile:

I think the auto-generate-types-from-ffi project feels like a valuable spike, with the outcome that "actually this will work, but maybe not be as useful as it first looked"

which I think is a good contribution, that you could consider finished without feeling too guilty (unless you want to keep going because you think it might yield more value, idk)

back to those examples, so with CLI specifically, that is identical for each language wrapped up isn't it? I get the programatic verifier etc is going to have different examples :thinking_face:

Yes, although where you might put it differs between languages. For example, it's valid inside an npm script, because pact-js exposes it to npm.

you don't need a custom script to use the CLI in pact-js

(I may be lacking a bit of domain knowledge here across the various languages which probably doesn't help)

on the python side you have the pact-verifier "binary" you call from a shell as one part, but then also the python function for verifying you're calling in the code I'm firstly talking about that binary, where the python code is literally taking the args you give it on the shell and then calling the ffi library with it Secondly is the programatic .verify method(s), which is where the type generation comes in and gets more complicated

> (I may be lacking a bit of domain knowledge here across the various languages which probably doesn't help) This is the IDEAL time to write docs. Because you'd be learning the concepts

I'm torn between asking is that not the same on the pact-js side / telling myself to RTFM :smile:

In terms of dropping or continuing, on the python side with the pact-verifier, I think that's simple and clean enough that I'm not sure why you (as in "one" rather than anyone specific!) wouldn't want to have the one less place to even have to think about For the other part around types I think there could be value but I'd happily just drop, I think it might be "too late" for this time unless there's more of a "yes that looks useful" since as you say, it's largely already done the first time anyway I've had fun finding out about Rust and FFI regardless so it's all good :slightly_smiling_face:

> wouldn't want to have the one less place to even have to think about The challenge is that sometimes autogenerated implementations become more things to think about longer term. Of course, if it's valuable to you / pact-python, I'm definitely not suggesting stopping. I'm also planning to use the introspection you added to the rust side to do sanity checks in pact-js. So, thank you!

Man, everytime I say ?I?m going to respond to Mike? I come back and there is a novel in front of me :laughing:

so, I?ve read most of the conversation. I?m currently on the side of ?it could probably be improved, but also it?s not the biggest pain point?.

which doesn?t mean it shouldn?t be solved, but it?s probably a little further down the list. Manually mapping arguments hasn?t been a big problem and from a time-to-market perspective, the proposal probably won?t shift that all to significantly.

If I could hijack the conversation toward big problems that cost us the most time / effort: 1. Documentation (as Mike has mentioned and we have discussed in a few places) having an actual guide that takes everyone from first consumer test, to completed Nirvana with the language specific examples and uses the CLI for key moments would be a massive win. 2. Getting onto v3 / rust core (which also needs some better documentation/guides for developers) 3. Having a feature spec (cucumber or otherwise) that each language should be implementing to ensure consistency with implementation and usage (2) 4. Consistent documentation across projects. Ideally, everyone goes to http://docs.pact.io/<language url>, instead of various GH repositories. This also goes for Pactflow documentation

Documentation is probably the highest priority, because it?s what leads to the most questions/time spent on slack, away from building new features (e.g. [2])

Getting onto the Rust core is strategically important, because having different specification versions and inconsistent experiences acrosns languages is another big class of confusion/problems

The biggest blocker to (1) is just time and getting headspace to do it. A good spike to iterate on the format is probably the starting point

Biggest blocker to (2) is the provider verification logging, and better developer documentation, and of course, implementation

(3) is something @greg595au has been agitating a bit about, and would love to give him some support around it if we think it?s a good idea

has joined #libpact_ffi-users

(4) requires coordination across Pactlow and OSS folks, and some thinking about the commercial and other impacts of doing so. We all agree it?s a bit messy though, and could be improved (we have some good data/user research on the Pactflow side to back it up though)

> Man, everytime I say ?I?m going to respond to Mike? I come back and there is a novel in front of me You've heard of "two wrongs don't make a \"right\"" :smile: (actually that wasn't as bad as it looked when I saw on Mobile :smile: )

Tim and I had a call chat yesterday which was nice as well as helpful :slightly_smiling_face: Where I'm currently up to: ? I'm thinking I'll leave the Python pact-verifier largely as-is, using the Rust method to auto-magically provide the args and so on, since it Just Works already (needs tidying up a little and maybe a few more tests, but there's not really anything to "go wrong" there) ? For the more contentious verifier programatically, shelve that for now, I will leave in a generate script for reference/manual use and use the class it's created so far but not progress wiring up to run the generate script during package etc, that needs tidying up of where it's up to Logging: ? I think the stdout going via the logger [which can then just print straight to stdout if desired!] etc at least as an option could be beneficial, but now understand better the pain point around logging levels etc, so leave that for now ? Going to spike a little around what logger options there are to try and split out the rust/pact logs. It looked like some of the other loggers had a nice way to "if you already have logging this is how you can hook into/replace existing macros so you can use this logger instead with only 2 lines of code" for example, which might work to do something there. I came across some examples this morning that looked like it might be able to split out the logging levels based on crates which might be a really quick win but need to play around with it Docs: ? I like docs, more than happy to focus there ? (3) I like that idea, why not try and structure the docs around that even? Then you can have consistent docs across all languages with examples of everything you want to do? ? (4) I think that needs some thought on what that would mean exactly, unless you're going down a round like CDK for example where the various language docs are largely autogenerated, I would think you would want as little as possible documentation in a language specific doc, and as much as possible in a Pact doc which has the examples for the various language syntax (thinking of the matcher for example), there's no point having copy pasted docs for each language, it's just another place to update and then improvements to one language don't benefit the other vs single source of truth

(4) definitely needs a lot of coordination to avoid upset over "why are you deleting all my docs for language x" -> "I'm not they're just over here now and I've added in all these other examples someone had done in language y"

As a JS maintainer, I certainly would welcome "here's a PR that deletes your docs and replaces them with templates to fill in for the central docs"

For sure, I just mean communicating what is happening so there aren't concerning surprises

#libpact_ffi-users Can someone please check the performance of consumer tests in their library using the Rust FFI approach on Windows please? In PactNet we get really poor performance (each test taking ~2s) with the mock server, but this doesn't happen on Linux or when there's a proxy in the way (using Fiddler) on Windows either. It's all just plain standard .Net Code and the performance is really poor. There's some more detail about things I've done to try and work out why it happens here: https://github.com/pact-foundation/pact-net/issues/323 tl;dr it's only when you use the Pact mock server and only on Windows

Oooooooooookay... So turns out if I replace `localhost` with `127.0.0.1` then the tests are super fast. Why on earth are they slow with `localhost` then?!

Hostname resolution?

Must be doing a DNS lookup, which is timing out.

I think it was first trying to bind to an ipv6 address

i.e. `localhost` was mapped to `::1` and then it falls back to other IPs

Should we support ipv6 in the mock server?

Oh I know this one! Windows is suuuuper slow at resolving ipv6 / 4 fallbacks because it actually follows the standards. Everyone else ignored them.

Hm, not entirely clear on the FFI libs required, just comparing between what was in the python FFI download, and the js's sh script, js has: 'nix: linux-x86_64.so.gz osx-x86_64.dylib.gz osx-aarch64-apple-darwin.dylib.gz win: windows-x86_64.dll.gz windows-x86_64.dll.lib.gz On the python side I've got: ```PACT_FFI_FILENAMES = [ "libpact_ffi-linux-x86_64.a.gz", "libpact_ffi-linux-x86_64.so.gz", "libpact_ffi-osx-aarch64-apple-darwin.a.gz", "libpact_ffi-osx-aarch64-apple-darwin.dylib.gz", "libpact_ffi-osx-x86_64.a.gz", "libpact_ffi-osx-x86_64.dylib.gz", "pact_ffi-windows-x86_64.dll.lib.gz", "pact_ffi-windows-x86_64.dll.gz", "pact_ffi-windows-x86_64.lib.gz", ]``` Does anyone know what/when the various additional files are required? :thinking_face:

One of those is static and one is dynamic

You don't need both from each pair, it just depends on how you link them I think

This is what we use in pact-js:

except we rename them so we know what version they were meant to be when they were downloaded

:thinking_face:

this downloads them

yus, that's the one I was looking at for the list above :slightly_smiling_face:

I do pay attention to your links sometimes :smile:

[actually, slightly earlier one before a refactor I think, earlier in the chan anyway]

Haha! Sorry, I was repeating myself from a PM so that others could see it too

Also yes, this time I cleaned it up a bit before linking it :wink:

yeah I meant the now broken link one, helpfully slack still had the contents, didn't know it did that

> robust-bash.sh

bit of an oxymoron there :smile:

:stuck_out_tongue:

shellcheck + that lib, and you'll be laughing. I have a blog post about it somewhere

It includes the recommendation "don't write more than 200 lines in bash".

....whooops.

:smile:

ok so I should be able to lose the .a. ones then :+1:

hello everyone, Can you tell me what other language implementations are shipping pre-compiled FFI libs as [package] artifacts?

JS and .NET at the moment

Oh and the dart package

Python is WIP

Go can't package anything other than source code, but it uses the FFI

wow, nice. thank you for the response.

Why do you ask?

For context Tim, Perdo is looking at the Elixr implementation

the previous work done by @pact-slack integrated rust code directly (similar to Pact JS) and now that work is recommencing there, I?ve been recommending moving away from that approach.

It?s made even more difficult for Elixr users, because they?d actually have to have Rust/Cargo etc. installed on end-users machines (i.e. it?s not just a pain for maintainers, but also users)

Right! Cool

ya, i can understand that.

What?s the strategy with raw FFI? We, @andrew.jensen and I, can think of two options: 1. Set up a CI pipeline for `pact_elixir`, so that every time we publish a new version of the library, we compile the Rust code for Windows, MacOS, and Linux, then include those compiled binaries in the packageExpect the developer to install the Rust toolchain on their computer, and have them compile the Rust code, even though they are interacting with it as if it is C code 2. Expect the developer to install the Rust toolchain on their computer, and have them compile the Rust code, even though they are interacting with it as if it is C code Do you recommend either one of those approaches or yet a different one?

.

we publish the artifacts here: https://github.com/pact-foundation/pact-reference/releases/tag/libpact_ffi-v0.0.2

No need to compile rust!

your strategy should be to download the OS-specific FFI bundles at build time, embedding them into your elixr package

when developers install the elixr package, your code knows where to find the relative paths of the FFI libraries

with the FFI interface, you don?t need to think about rust at all. The libraries expose a C interface that can be directly used by any language that can interface to C (I believe Elixr can based on my reading). You just need to pop the libraries into a known location (e.g. the equivalent of `./node_modules` or `~./pip` ) and then link to it

Yes, definitely you shouldn't need to compile any rust. The binaries are already built for the architectures we support, you just need to link them using whatever C bindings Elixir has available

From experience with the other pact frameworks, it's best if you can bundle the binaries directly in whatever package manager `pact_elixir` is stored in

Thank you fellas

> your strategy should be to _*download*_ the OS-specific FFI bundles at build time, embedding them into your elixr package (Emphasis mine :laughing:) Aha! We hadn?t though of that being an ?option 3? but that seems like it should work. I?m not sure on all the details of how to do it idiomatically in Elixir but we can start looking into it.

> *at build time* ^ You can do this at the time you build the elixir package, not at the time the user builds

In pact-js, we do this with bash - here's the script (it also downloads the standalone ruby binaries): https://github.com/pact-foundation/pact-js-core/blob/master/script/download-libs.sh

Exactly. You want to ship a package that doesn't require anything special on the part of the user. No extra dependencies, or user build time downloads where proxies etc can get in the way

hello all, I am on a mac I cloned and build the `c` bindings/FFI project in https://github.com/pact-foundation/pact-reference when i run. I am getting a `dyld: Library not loaded: @rpath/libssh2.1.dylib` when I run the command ```src/consumer-verification basic src/libpact_ffi.dylib``` I copied `libpact_ffi.dylib` to the same directory where ?consumer-verification? is. I?ve tried installing libssh2 using Brew, i recreated the links to point to where the library lives and still seeing that error. I?ve tried other things like what?s in this article https://blog.krzyzanowskim.com/2018/12/05/rpath-what/ to no avail. Can someone point me to how to get around this? I am sorry, the setup appears to be trivial and it might be so but I can?t figure it out.

how are you linking to the dylib?

Are you using the c example in there, or are you writing your own FFI integration?

I?d honestly start by downloading the dylib directly from Github, and creating a standalone script that can load the dylib and execute a function. Perhaps the verifier, because it will spit output if you don?t pass the correct args which means it worked

That being said, dylib is a dynamically linked library - that seems to indicate it doesn?t know where libssh is

i am using the c example in there. i also downloaded the library directly from GitHub. Tried building it myself and the one i downloaded. i think the error is due to yet another library `libssl` that somehow the system is not finding even though it is on my machine in `/usr/local/Cellar` that is being pointed to via a soft link from a file in `/usr/local/lib`

i thought I would start by looking at the `c` example in there.

i am following the directions in the `README.md` at ?c/consumer-verification/README.md?

ah, I?m out - it?s C :laughing:

This example made sense to me: https://andrealeopardi.com/posts/using-c-from-elixir-with-nifs/

I think you can just skip to ?Loading NIFs in Elixir?

See if you can call this: https://docs.rs/pact_ffi/0.0.2/pact_ffi/fn.pactffi_version.html

and print it out

@matt.fellows are you thinking we should have a little bit of C code in the Elixir project in order to wrap the FFI lib, so it becomes a NIF? In order to make a C library into a NIF, it needs to be compiled with `#include "erl_nif.h"` and NIF-related args on the available functions. (See ?Defining a NIF? in the doc you linked) I see some downsides to doing it this way: ? Complexity of the pact_elixir library?s pipeline: we need to download the FFI bundle at package-time _and_ compile a C NIF wrapper around it at compile-time ? Complexity of the library?s code: we need to write NIF-friendly C shims around every FFI function, then Elixir shims around the NIF shims ? App build-time performance: We have to do the work to compile the C NIF around the FFI bundle Maybe we plan on using the https://erlang.org/doc/tutorial/introduction.html to raw C libs instead, like ports or port drivers, instead? That way we just rely on the FFI bundle itself.

No you don't need to write C code, you can just link the library directly (hence skip the step about C)

Therefore, we should not write a NIF wrapper, right? EDIT: to clarify, not sure I fully understand the implication in your message, so just wanted to double-check!

This is where I am out of my depth and may well be giving bad advice.

Most languages have a way to just link to a C library

I don't fully appreciate the complexities of the NIF tho

OK cool. Yeah I think we should be looking for those simpler approaches as well. I haven?t had to write one so I?m a little out of my depth too!

Our libraries export a C Interface, so if you can make Elixr communicate with that you should be golden

So, in pact-js, we use a native wrapper provided by tooling that is designed to link from node. This means that: 1) We download the lib + bundle it before the pact-js package is published for users 2) When users install, there's a compile step (abstracted from us and users) provided by the node linking tooling If that tooling doesn't exist in Elixir and there are hoops to jump through to call a C interface, you might have to do something custom

hopefully that isn't necessary, or whatever it is can be done automatically easily

From the limited context I have at this point - Erlang+Elixir NIFs are an abstraction on top of FFI that give you more safety. You know how there are new classes of errors that can occur in FFI that wouldn?t otherwise happen in higher-level languages (segfaults, some types of memory leaks, etc.) so NIFs add some extra checking on inputs and outputs that go across the FFI bridge, so if something crazy happens in the FFI code, it?s less likely to blow up the higher-level runtime. But you have to opt into NIFs. In other words, you can?t create a NIF by just linking Elixir straight to a C lib, you need that C lib to have NIF headers.

@tjones could you post a link to the source of that wrapper? That actually sounds pretty analogous to NIFs!

I... can, but we don't even touch it

Oh, the wrapper code is _generated code_, that?s what you?re saying, right?

from pact-js' perspective, we just tell that wrapper to link the ffi lib (and describe the interface that we want)

OK awesome, I?m hoping we can find something similar in the Elixir ecosystem

I'd be very surprised if there isn't

a quick google suggests that we _could_ parse the .h file and write a NIF wrapper fairly easily

sooo hopefully someone else has already done that

Yeah I?d love to piggyback on a battle-tested implementation of that header parsing

For interest, this is how we define it (partial implementation): https://github.com/pact-foundation/pact-js-core/blob/feat/ffi-consumer/src/ffi/declarations.ts

(but I don't think that's going to be useful to you)

Sorry I'm just getting jab #2... Will jump back in here later

Thanks for the link. I like seeing all the declarations there, that?s a good way to see the shape of the functions we need to call. I?m trying to figure out what libs we might need that would behave similar to the `ref-napi` and `ref-struct-di` packages. I don?t fully grok what they?re doing yet but I can see they?re providing TS definitions and? emulations of C structs through JS buffers?

Anyway, this gives us some great things to research. Thank you both for the help!

They're providing the bindings of node types to C

so, we don't have to do anything special with C strings

(for example)

thanks matt a Timothy for your answers, thank you Andrew for the questions. Now i have a better idea as to what approach to take.

@matt.fellows you said > Our libraries export a C Interface, so if you can make Elixir communicate with that you should be golden Do you mean in the Pact Reference Project? If not that project then which project? on an unrelated note: I cloned the pact-reference libpact ffi project and got the javascript and the c projects to build. Just yesterday I got the `c` binary to run. I did this with the hope of familiarizing how these languages define and then use the .dylib Pact libraries. From what was said above I think I have ideas as to how to take our next steps.

By C interface, I don?t me C code, I mean something that can interop with C itself (usually shipped in the form of a dynamic or static library. We suggest using one of the dynamic libs: .so, .dylib, .dll)

But it sounds like you have a grasp on it! :clap:

@uglyog is this what I think it is https://github.com/pact-foundation/pact-reference/commit/42be9eb8? :eyes: Do we need to migrate to the newer provider verifier methods for this to work, or is the second log extraction function (`pactffi_verifier_logs_for_provider`) that just uses the name of the provider sufficient? https://github.com/pact-foundation/pact-reference/commit/42be9eb8#diff-0683cbee93e01f96b27383c0954421fc5be638947d54311f880ba9b84ba2cb61R652

cc: @tjones

ok great. yeah, i think i got it. thank you

A warning for everyone - if you call `pactffi_write_pact_file`, it writes the pact file even if the test run was unsuccessful.

Thanks. I don't think we need this for pact-js - what we do need is to be able to have the log levels standardised with pact-js.

but it's a problem because Rust's logs are very noisy. I think the solution probably lies in having two loggers - one for the pact framework, and then the library logger for maintainers

Yes, sorry I was confused about what you wanted the other day - have had too many of these chats with people recently

I can look at the default noise (i suppose that would be INFO level). Anything there that is more about debugging a problem will go back to debug level. I?ll start there and we can iterate

I?ll use the existing Ruby output as a guide also (there are many notices and I think they are important)

Having a look at this, or rather attempting to but a bit stuck getting started :slightly_smiling_face:

Right, trying to take a look at the logging, but I'm having some difficulty reproducing some of the issues, I'll reply in thread to myself here to avoid spamming with long copy/pastes :slightly_smiling_face: TLDR: can't get it to spew out noisy logs as expected

So, I'm on this branch: >  mgeeves@bearly:~/dev/GitHub/pact-foundation/pact-js-core$ git branch > * feat/ffi-consumer >   master I've changed the logLevel to trace: > mgeeves@bearly:~/dev/GitHub/pact-foundation/pact-js-core$ grep logLevel test/verifier.integration.spec.ts >     logLevel: 'trace' as LogLevel, And added in using the DEFAULT_ARGS to all the tests (was only used on 2?) > mgeeves@bearly:~/dev/GitHub/pact-foundation/pact-js-core$ git diff | head -40 > diff --git a/test/verifier.integration.spec.ts b/test/verifier.integration.spec.ts > index 8f037b2..88a54e1 100644 > --- a/test/verifier.integration.spec.ts > +++ b/test/verifier.integration.spec.ts > @@ -18,7 +18,7 @@ describe('Verifier Integration Spec', () => { >    const pactBrokerBaseUrl = `http://localhost:${PORT}`; >    const monkeypatchFile: string = path.resolve(__dirname, 'monkeypatch.rb'); >    const DEFAULT_ARGS = { > -    logLevel: 'debug' as LogLevel, > +    logLevel: 'trace' as LogLevel, >      providerVersion: 'VERSION', >    }; > > @@ -52,6 +52,7 @@ describe('Verifier Integration Spec', () => { >        it('should return a successful promise', () => >          expect( >            verifierFactory({ > +              ...DEFAULT_ARGS, >              providerBaseUrl: providerBaseUrl, >              pactUrls: [ >                path.resolve(__dirname, 'integration/me-they-success.json'), > @@ -64,6 +65,7 @@ describe('Verifier Integration Spec', () => { >        it('should return a successful promise', () => >          expect( >            verifierFactory({ > +              ...DEFAULT_ARGS, But if I try and look at the levels coming out: > mgeeves@bearly:~/dev/GitHub/pact-foundation/pact-js-core$ npx mocha test/verifier.integration.spec.ts 2>&1 | grep -E "DEBUG|ERROR|INFO|TRACE|WARN" | awk {'print $2'} | sort | uniq -c >       1 07:54:03.009 >       1 07:54:03.035 >       1 07:54:03.036 >       2 07:54:03.038 >       2 07:54:03.045 >       1 07:54:03.046 >       1 07:54:03.047 >       3 07:54:03.048 >       2 07:54:03.049 >       2 07:54:03.051 >       2 07:54:03.053 >       2 07:54:03.056 >       1 07:54:03.060 >       1 07:54:03.061 >       1 07:54:03.064 >       1 07:54:03.065 >       2 07:54:03.066 >       2 07:54:03.068 >       2 07:54:03.069 >       1 07:54:03.070 >       1 07:54:03.071 >       1 07:54:03.072 >       4 ERROR >      90 INFO >      34 WARN Those timestamps are from a slightly different formatted entry: > mgeeves@bearly:~/dev/GitHub/pact-foundation/pact-js-core$ npx mocha test/verifier.integration.spec.ts 2>&1 | grep "+0000] INFO" | tail -2 > [2021-10-02 07:54:28.500 +0000] INFO (1689259 on bearly): pact-core@13.1.7: Verifying Pact Files > [2021-10-02 07:54:28.501 +0000] INFO (1689259 on bearly): pact-core@13.1.7: Verification successful [9:00 AM] I'm not getting anything producing excessive Rust logs :thinking_face:

Logs like this one are the type Tim was talking about ideally being reduced since they are more verbose than you would probably want as INFO when looking as a pact user: > [2021-10-02T08:07:03Z INFO pact_verifier::provider_client] Received response: Response ( status: 200, headers: Some({"access-control-allow-origin": ["*"], "content-length": ["26"], "content-type": ["application/json; charset=utf-8"], "etag": ["W/\"1a-ztXXi0g2amFzJAkK4azzbA+THms\""], "date": ["Sat", "02 Oct 2021 08:07:03 GMT"], "connection": ["keep-alive"], "x-powered-by": ["Express"]}), body: Present(26 bytes, application/json;charset=utf-8) ) .... but I can't see even with it set to TRACE a huge amount of logs coming from the Rust libs

I was expecting to get flooded with the low level lib logs, but don't seem to be getting any :thinking_face:

I may have misunderstood the starting point with this, if for example the logs being sent back via ffi are specifically the pact ones, and the low level Rust logs are already excluded, in which case I'm starting in the wrong place :smile:

Just on mobile (of course) but they definitely don't look like trace logs to me You could probably just invoke the provider verifier outside of node JS directly and just point at a pre canned pact file and any http server (whether it implements the pact or not)

I.e. compile it locally or pull the latest binary down

:thinking_face:

When you say directly, the ffi still needs to be loaded in by something, JS, python etc

The rust core also has a CLI you could use

Yeah, the CLI is what I'm talking about. It's exactly the same code that fires. The only difference is how the arguments get there

:thinking_face: so I've built pact_cli

I assume not this one though

> mgeeves@bearly:~/dev/GitHub/pact-reference/rust$ ./target/debug/pact-file-verifier -d /home/mgeeves/dev/GitHub/pact-python/examples/pacts --loglevel trace > Verification result is OK > > 1) /home/mgeeves/dev/GitHub/pact-python/examples/pacts/pact-consumer-one-pact-provider-one.json: OK > > > There were 0 error(s) and 0 warning(s) in 1 file(s)

:facepalm: ok pact-verifier-cli, I didn't scroll

and for my reference later, so then: > $ ./target/debug/pact_verifier_cli -d /home/mgeeves/dev/GitHub/pact-python/examples/pacts --loglevel trace --port 35159 seems to be it

js-core bugfix from Tim and I think we're almost ready to start :smile:

Yes. Someone broke the logging in js-core. And by someone I mean me

Quick question - the `include_wip_pacts_since` argument for the Pact Broker, is there any documentation on what form that can take? I've had a look and can't find any.

Looks like it should be YYYY-MM-DD going by https://github.com/pact-foundation/pact-reference/blob/master/rust/pact_ffi/src/verifier/mod.rs

> /// If the `include_wip_pacts_since` option is provided, it needs to be a date formatted in > /// ISO format (YYYY-MM-DD).

I think it actually can take any date like thing, but ISO format is definitely supported

It is documented here: https://docs.pact.io/pact_broker/advanced_topics/wip_pacts/#to-start-using-the-wip-pacts-feature

Examples are all ISO format

Sounds like a bug if it can accept anything other than ISO :grinning:

I seem to recall that Beth said the gem it used could expect things like ?Wednesday 3rd March 2020?

but I may be remembering wrong

Yeah, weirdly in my test for this feature it uses `5d` (as in '5 days ago') to pass in. If it has to be a date then I can change the API to make sure we pass in a proper Date object since currently it's just a string

:open_mouth:

From an API/testing pov that sounds like something likely to get unexpected/difficult to reproduce etc behaviour :thinking_face: Is that something with an actual use case people want? (Interested to understand rather than "that's horrible how could you!" :grinning: )

Yeah I have no idea where I even got that from :joy: I'll fix it

:joy:

I think this confirms my suspicion about it dealing with "date like" formats

OK I've made that a proper date in PactNet now: https://github.com/pact-foundation/pact-net/pull/333

Has anyone upgraded to FFI v0.0.3 yet? As soon as I do the verifier starts panicking, but without any output in .Net I can't work out why... 0.0.2 and earlier is absolutely fine, and I'm literally just upgrading the library version with no other changes

Oh dear, this looks bad... I thik it's related to the change to use native cert stores: ```$ RUST_BACKTRACE=full /d/Downloads/pact_verifier_cli.exe --provider-name "Event API" --hostname localhost --port 9222 -- filter-consumer "Event API Consumer" --file 'C:\git\pact-net\samples\EventApi\Consumer.Tests\pacts\Event API Consumer-Ev ent API.json' --state-change-url http://localhost:9222/provider-states Verifying a pact between Event API Consumer and Event API thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: InvalidData, error: Custom { kind: InvalidData, error: BadDER } }', C:\Users\runneradmin\.cargo\registry\src\github.com-1ecc6299db9ec823\reqwest-0.11.4\src\async_impl\http://client.rs:297:65 stack backtrace: 0: 0x7ff66797537f - onig_get_regex_by_callout_args 1: 0x7ff66798c23a - onig_get_regex_by_callout_args 2: 0x7ff66796ec18 - onig_get_regex_by_callout_args 3: 0x7ff667977f66 - onig_get_regex_by_callout_args 4: 0x7ff667977a49 - onig_get_regex_by_callout_args 5: 0x7ff6679785c5 - onig_get_regex_by_callout_args 6: 0x7ff6679781b1 - onig_get_regex_by_callout_args 7: 0x7ff667975c9f - onig_get_regex_by_callout_args 8: 0x7ff667978109 - onig_get_regex_by_callout_args 9: 0x7ff6679e18a0 - onig_unicode_define_user_property 10: 0x7ff6679e19b3 - onig_unicode_define_user_property 11: 0x7ff66767e528 - onig_get_options 12: 0x7ff6672ef2f6 - <unknown> 13: 0x7ff667347880 - <unknown> 14: 0x7ff667323e3e - <unknown> 15: 0x7ff6672fc7e0 - <unknown> 16: 0x7ff66730cd28 - <unknown> 17: 0x7ff66731467c - <unknown> 18: 0x7ff6672d6b59 - <unknown> 19: 0x7ff6673235bf - <unknown> 20: 0x7ff6672f5472 - <unknown> 21: 0x7ff667350283 - <unknown> 22: 0x7ff66735996b - <unknown> 23: 0x7ff6673200aa - <unknown> 24: 0x7ff6673296a6 - <unknown> 25: 0x7ff667350cd6 - <unknown> 26: 0x7ff66730d97c - <unknown> 27: 0x7ff667978b26 - onig_get_regex_by_callout_args 28: 0x7ff6673297c7 - <unknown> 29: 0x7ff6679c64d0 - onig_unicode_define_user_property 30: 0x7ffdd0ab7034 - BaseThreadInitThunk 31: 0x7ffdd1802651 - RtlUserThreadStart```

I've raised the above issue here: https://github.com/pact-foundation/pact-reference/issues/156. It's definitely something to do with cert stores as the error comes from `reqwest` and relates to DER certs.

If anyone has integration tests checking the pact file is written properly, also note that FFI outputs slightly different content on Windows and Linux: https://github.com/pact-foundation/pact-reference/issues/157

Yes, here's a verifier run with v0.0.3: https://github.com/pact-foundation/pact-js-core/runs/3755501336#step:4:1713

(note that the build fails because we're having trouble with the ffi wrapper on node 16, but I think that's unrelated. I tried upgrading to 0.0.3 on the off-chance it would fix it)

(also, it doesn't mean it works - those tests are not especially intensive)

:open_mouth:

I mean, they do do real verification. But, I wouldn't say it's a full suite

Just tested the latest locally, and it works against a pactflow hosted account (good)

So I thought, i?ll just double check it?s not also susceptable to the Let?s Encyrpt issue

```11:50:26 [ERROR] Failed to load pact - Could not load pacts from the pact broker 'https://host.with.letsencrypt.cert.com' - IO Error - Failed to access pact broker path '/' - error sending request for url (https://host.with.letsencrypt.cert.com/): error trying to connect: invalid certificate: UnknownIssuer. URL: 'https://host.with.letsencrypt.cert.com' Failures:```

Shit!

but then realised that isn?t a new Let?s Encrypt endpoint and was a bumsteer from a poster on GH. My mac doesn?t trust it, so I stopped panicking?

Line 297 is https://docs.rs/reqwest/0.11.4/src/reqwest/async_impl/client.rs.html#297, which is exactly where you?d expect to see problems in rustls-tls-native-roots

From what I can see, you must have an invalid DER certificates in your system which is causing that issue. Looking at the https://docs.rs/reqwest/0.11.4/src/reqwest/async_impl/client.rs.html#1695-1696, it?s assuming that the native certs library doesn?t fail (hence the panic), but that just defers to this https://github.com/rustls/rustls-native-certs/blob/fb25baaf27c4e70793c1600c844d6a644d0813c0/src/rustls.rs#L31, which attempts to load each certificate into the trust store. but if ANY certificate is invalid, it instead bails out. That seems strange to me, but perhaps there is a good reason for that.

has joined #libpact_ffi-users

Ohh, that's novel, I left a reference for myself and actually found it again :joy:

Is it true that if we use `pactffi_using_plugin` , then we have to use `pactffi_interaction_contents` , and we can't use other ffi functions like: ? `pactffi_message_with_contents` ? `pactffi_with_body` ?

Yes, but that is only for content from plugins

It should be integrated into the other methods at some point, I'm just not sure how it would work

Pact plugin driver doesn't give me the reason why the plugin can not be started: > 2022-01-06T01:30:14Z ERROR pact_plugin_driver::child_process] Timeout waiting to get plugin startup info: timed out waiting on channel > [2022-01-06T01:30:15Z ERROR pact_ffi::plugins] Could not load plugin - Plugin process did not output the correct startup message in 60 seconds: timed out waiting on channel

If I run the csv plugin manually, I got this error:

I saw this problem on my Mac a month or two ago, I think there was an issue Ron was working through

```./pact/plugins/csv-0.0.0/pact-plugin-csv 08:30:45 ./pact/plugins/csv-0.0.0/pact-plugin-csv: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./pact/plugins/csv-0.0.0/pact-plugin-csv) ./pact/plugins/csv-0.0.0/pact-plugin-csv: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ./pact/plugins/csv-0.0.0/pact-plugin-csv) ./pact/plugins/csv-0.0.0/pact-plugin-csv: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./pact/plugins/csv-0.0.0/pact-plugin-csv)```

Are you running it in Alpine Linux?

ahh

No, I am running on Linux Mint 20.2 (Based on Ubuntu 20.04)

Quick google: https://superuser.com/questions/537683/how-to-fix-lib-x86-64-linux-gnu-libc-so-6-version-glibc-2-14-not-found

Can you confirm what version of glibc you have?

You will probably need to install 2.14, or build the plugin against the older version

> ldd --version > ldd (Ubuntu GLIBC 2.31-0ubuntu9.2) 2.31

right behind 2.32

Probably easier just to build the plugin on your OS

I built it myself and it work fine.

I'm just not sure if it's user friendly

Yeah, we will probably need to support the LTS Linux versions, so will need to build it for different glibc versions

How can we verify provider with pacts created by plugins?

But this one is just a prototype

The verifier will try load any plugin required. It will have been written to the pact file

The plugin will need to be installed where the verifier runs

Are there any extra steps or I just run like normal? I asked because the provider verifier failed without any reason. ```Xdebug: [Step Debug] Could not connect to debugging client. Tried: 127.0.0.1:9003 (through xdebug.client_host/xdebug.client_port) :-( PHPUnit 9.4.2 by Sebastian Bergmann and contributors. Test 'Provider\PactVerifyTest::testPactVerifyConsumer' started Verifying a pact between test_consumer and test_provider Given a message Given You can hear happiness staggering on down the street an alligator named Mary exists generates a message which includes metadata "routing_key" with value "wind cries" (OK) "queue" with value "wind cries" (OK) has a matching body (OK) footprints dressed in red generates a message which includes metadata "routing_key" with value "And the clowns have all gone to bed" (OK) "queue" with value "And the clowns have all gone to bed" (OK) has a matching body (OK) Test 'Provider\PactVerifyTest::testPactVerifyConsumer' ended Time: 01:40.082, Memory: 20.00 MB There was 1 failure: 1) Provider\PactVerifyTest::testPactVerifyConsumer Failed asserting that false is true. /home/tien/Projects/pact-php/example/tests/Provider/PactVerifyTest.php:63```

Maybe the reason is I didn't set the value for `PACT_PLUGIN_DIR` env in provider verify tests. I will test later today. But the output does not contains any clue make it hard to debug.

That's exactly the issue. I added the env `PACT_PLUGIN_DIR` and it work fine now

I'm testing protobuf plugin and here are some problems I got: ? I downloaded this https://github.com/pact-foundation/pact-plugins/releases/download/protobuf-plugin-0.0.0/pact-protobuf-plugin-0.0.0.zip and extract to `/custom/path/to/pact/plugins/protobuf-0.0.0` (configured by `PACT_PLUGIN_DIR`), but it does not work, then I realized that I need to move `bin` and `lib` directories inside `pact-protobuf-plugin-0.0.0` directory up to parent directory(to `protobuf-0.0.0`) ? The file `/custom/path/to/pact/plugins/protobuf-0.0.0/bin/pact-protobuf-plugin` need to be executable (it's not by default) Do I need to create tickets in github for them?

Does Pact Protobuf Plugin support `oneof` feature? I'm getting these error messages: ? `Failed to call out to plugin - Request to configure interaction failed: Message ShapeMessage has no field implementation` ? `Failed to call out to plugin - Request to configure interaction failed: Message ShapeMessage has no field shape` Here is my proto file: ```syntax = "proto3"; package plugins; option php_generic_services = true; service Calculator { rpc calculate (ShapeMessage) returns (AreaResponse) {} } message ShapeMessage { oneof shape { Square square = 1; Rectangle rectangle = 2; Circle circle = 3; Triangle triangle = 4; Parallelogram parallelogram = 5; } } message Square { float edge_length = 1; } message Rectangle { float length = 1; float width = 2; } message Circle { float radius = 1; } message Triangle { float edge_a = 1; float edge_b = 2; float edge_c = 3; } message Parallelogram { float base_length = 1; float height = 2; } message AreaResponse { float value = 1; }```

There is not much we can do about that, those bundles are produced that way by the Gradle application plugin. I've ported the plugin to one that is written in Rust. https://github.com/pactflow/pact-protobuf-plugin

oneOf is not supported yet. See https://github.com/pactflow/pact-protobuf-plugin#supported-features

I didn't know this repository exist. Let me try

You will have to build it yourself, as you will also have the glibc issue

But I'll update the CI build to create a LTS version as well

I will. Thanks for your support. You can do it later. Enjoy your holidays.

I figured out how to use it properly (at least what I think). So `oneof` is not a problem for now.

Actually `pact-protobuf-plugin` work fine on my machine, I don't need to build

Replaced protobuf plugin java version by rust version, I can see that the `body` and `matchingRules` of `request` section is removed. I think it's a bug.

Can you raise an issue for that

I can't reproduce this different, so I can't report it. But because my test passed with java version, then now failed with rust version, so I think something wrong here, but I don't know why. I managed to print out `mismatches` : ```[{"method":"POST","mismatches":[{"actual":"","expected":"","mismatch":"Failed to compare the Protobuf messages - Did not find a field with number 2 in the descriptor, Message is Some(\"AreaResponse\"), Fields are {\"value\"}","path":"","type":"BodyMismatch"}],"path":"/calculate","type":"request-mismatch"}]```

Can you tell me how to show/get plugin's log (or debug info) when running consumer or provider tests?

The logs are captured at the level that your test runs as, so you shouldn't have to do anything. Just set your logging to debug.

you means `LOG_LEVEL=debug` ? I think it does not work for me `LOG_LEVEL=debug phpunit --debug -c example/phpunit.plugins.xml`

Oh, sorry, it is invoked via FFI. You need to set the log level via https://docs.rs/pact_ffi/0.1.5/pact_ffi/log/fn.pactffi_log_to_stdout.html

Ideally, it should be set to the log level set in php

Let me try

I tried ffi functions and it seem does not work for me ``` $this->ffi->pactffi_init('PACT_LOGLEVEL'); //$this->ffi->pactffi_logger_init(); //$this->ffi->pactffi_logger_apply(); //$this->ffi->pactffi_log_to_stdout($this->ffi->LevelFilter_Debug); //$this->ffi->pactffi_log_to_stderr($this->ffi->LevelFilter_Trace); $this->ffi->pactffi_log_to_file(__DIR__ . '/log.txt', $this->ffi->LevelFilter_Debug);```

The file `log.txt` is empty for me

You need to call `pactffi_logger_apply` at the end

It work now by combining `pactffi_log_to_stdout` and `pactffi_logger_apply` Then I realized `$this->ffi->pactffi_init('PACT_LOGLEVEL')` output same log, but with colors so it look better. All I need to do is using `PACT_LOGLEVEL=debug` , not `LOG_LEVEL=debug` Silly me.

I reported the issue here https://github.com/pactflow/pact-protobuf-plugin/issues/1

Thank you!

@kyle.florence has left the channel

Are there any other docs for the new verifier FFI handles approach? There aren't many docs on the functions themselves (the only arg docs are basically for when it's a number interpreted as a boolean). I'm struggling to work out how to actually use this

Maybe I'm just grumpy this morning, but I'm finding the FFI approach really difficult to work with. I've upgraded to the latest FFI (0.1.6) in order to start moving to verifier handles, and now all the existing verifier tests fail with an error code which just says they panicked. I have nothing to go off there. I don't have an awful lot of time to work on it, so now most of that is gonna be taken up trying to debug what breaking change there is in the FFI. Do we publish a changelog or an upgrade guide or something to help guide maintainers through breaking changes to the FFI? It's very difficult to dip in and out as an open source volunteer otherwise, and just kinda makes me not want to do it.

Well at least the CLI panics as well ```$ pact_verifier_cli \ > --provider-name \ > "Event API" \ > --hostname \ > localhost \ > --port \ > 9222 \ > --file \ > "C:\dev\http://github.com\pact-net\samples\EventApi\Consumer.Tests\pacts\Event API Consumer-Event API.json" \ > --state-change-url \ > http://localhost:9222/provider-states Verifying a pact between Event API Consumer and Event API thread 'main' panicked at 'Client::new(): reqwest::Error { kind: Builder, source: MissingOrMalformedExtensions }', C:\Users\runneradmin\.cargo\registry\src\github.com-1ecc6299db9ec823\reqwest-0.11.7\src\async_impl\http://client.rs:1251:38 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace```

Oh no, I think it's native TLS certs again...

> It's very difficult to dip in and out as an open source volunteer otherwise, and just kinda makes me not want to do it. This was my experience too

I think it's worth taking a step back and designing the interface to the shared core so that it has first-class support for the client frameworks. For example, at the moment it's hard to know what the lifecycle is intended to be for the different methods (eg, some methods can be called more than once, some silently clobber information - see https://github.com/pact-foundation/pact-reference/issues/172). A related issue is that if a password is passed via an environment variable as well as via the options, then the verifier fails with an error message that doesn't really describe the situation unless you know how it is implemented. At the moment, we have to implement this all client-side, which would mean re-implementation in every framework. I don't think this is the intention of the shared core, but without documentation I can't tell if it is the intention or not.

I also can't tell what preconditions are meant to be met for each method.

I'm leaving the project at the end of the month anyway, but my current feeling for pact-js is that it would be less trouble to have our own native JS core.

:thinking_face: I really like the idea of shared etc, but I can see how that's really hard to do from an open source pov, imo you need to be able to have "group" discussions and have everyone on board with a direction etc, which seems very hard in an "async" way of working :thinking_face:

> A related issue is that if a password is passed via an environment variable as well as via the options, then the verifier fails with an error message that doesn?t really describe the situation unless you know how it is implemented. that is not an issue with the handle based interface that Adam is moving towards. The previous one was just a slimy interface on top of the CLI, but the new one is different altogether and doesn?t have this problem (and others).

> Oh no, I think it?s native TLS certs again... I need to refresh where that issue got to. I seemed to recall reqwest needed an update to the latest and/or there was a PR to reqwest that solved the problem. I?ll add to review this week

The new FFI has some confusing points as well though (that don't lend to a fluent interface), and some args that I just can't work out. e.g. this will use basic auth over token auth if you provide both: ```fn pactffi_verifier_broker_source( handle: *mut handle::VerifierHandle, url: *const c_char, provider_name: *const c_char, username: *const c_char, password: *const c_char, token: *const c_char )```

And I can't work out what the last param of this one does: ``` fn pactffi_verifier_set_filter_info( handle: *mut handle::VerifierHandle, filter_description: *const c_char, filter_state: *const c_char, filter_no_state: c_uchar )```

Oh does that mean "only run interactions if they have no provider state"? But then what if you pass a `filter_state` as well?

> I?m leaving the project at the end of the month anyway, but my current feeling for pact-js is that it would be less trouble to have our own native JS core. Let?s try and be constructive here. The shared core is a very large beast and any attempt to rebuild it will run into issues of backwards compatibility, interface design, teething issues etc. Unless we can get the whole community to build together, and even then? It was largely built in personal time (similar to Adam?s comment) and that makes it even more difficult. We?re investing more into it now since Pactflow has been a thing, which has led to several important advancements. This being said, I think it would be wise to try and get our collective thoughts for improvement together. What do we think the best way of doing that is?

To answer my own question - if you specify both then the filter wins and the final arg is ignored

Sadly Adam I?m not really across the handle based interface, but hopefully Ron can chip in with some guidance. I just know that it apparently solves the existing interface problem (what other issues it might produce I can?t yet say!)

I do know a few of the models changed (I tagged you in a thread a while back, which I know, is not ideal). We discovered a few of the structs were exposing their insides, and Ron converted them to Opaque types (essentially, a uint)

I think one big hurdle to have this used in prod at a wide scale is that when it fails I just got an "it panicked" return code. To debug that I had to run my test in the debugger to start my API, set a breakpoint to stop the test actually running and then manually call the API with the verifier CLI (which is using a different version of the crates to the FFI afaict). That's quite an involved debugging process, especially for an issue which probably only happens on specific machines (because of the native cert store). We can't really ask users to do that when they have issues, but without that panic info we're pretty stuck with support.

Yeah, it looks like there are a couple of libraries that have OS/platform type switches in them

TLS native certs is one, and there is a magic mime detection one that has different behaviour depending on runtime shared libraries. As a principal, I think we want to avoid this

> The previous one was just a slimy interface on top of the CLI, but the new one is different altogether and doesn?t have this problem (and others). I'm not complaining about that specifically, I'm saying the problem of error messages that might only make sense if you know how the implementation works seems to exist throughout the core.

I think in general, it would benefit from sitting down and thinking about what the best experience for clients would be

and what that boundary looks like

For me, the approach I would like is to agree on some values that guide the design - like I proposed for the logging levels

I?m sure there are a bunch of principles, so articulating those might be a good start and then we can iterate from there

It's weird because we've got like libraries depending on libraries, and I know the core is at the 0.x stage which says "breaking changes can happen". We really do need to keep those breaking changes to a minimum though, and write upgrade guides for maintainers if we do introduce them. Otherwise we've all got to go digging into the core every time we upgrade and it breaks, and as we've said it's a big beast

The feedback on the ?doesn?t lend to fluent interface? is interesting, because we?ve seen feedback that suggests it encourgase that (which in the context was a negative). The point here, is we ought to seek feedback from the community on what?s goig to work best, make a decision and move forward

> We really do need to keep those breaking changes to a minimum though, and write upgrade guides for maintainers if we do introduce them. Otherwise we?ve all got to go digging into the core every time we upgrade and it breaks, and as we?ve said it?s a big beast (edited) I think in the 0.y.z line there were some, but in the x.1.z line the position is no breaking changes. But yes, I agree

The one I was specifically thinking about was this one: ``` fn pactffi_verifier_set_verification_options( handle: *mut handle::VerifierHandle, publish: c_uchar, provider_version: *const c_char, build_url: *const c_char, disable_ssl_verification: c_uchar, request_timeout: c_ulong, provider_tags: *const *const c_char, provider_tags_len: c_ushort )```

That's just one big multi-purpose function, instead of more fine-grained ones which you'd typically get in a fluent interface

yep. If we add a new option, that method will break. (well, depends on the defaults, but probably not ideal)

back to the async issue, responsive to "this is weird, having problems with this change" vs a more planned "we are going to look at doing this, does it make sense", and getting some feedback before changes maybe?

Yeah that :+1: And the break will manifest as a segfault or something equally unhelpful at runtime, which isn't a great devex for maintainers

:smile: it's kind of sad, the whole rust......you can't get null pointers, they all have to be handled, everything is safe, right up to the point where you have to say FFI, unsafe, oh well :smiling_face_with_tear:

How would we like to collaborate on this? I think we?re going to have to accept async, because physics, but we could probably get a few face-to-face sessions (e.g. using Miro / google docs) and get a plan down. And then we can use tools like GH projects to manage things.

> The feedback on the ?doesn?t lend to fluent interface? is interesting, because we?ve seen feedback that suggests it encourages.... I would absolutely agree that I don't think it leads to a fluent interface, at least not from a pact-js perspective. Critically, the "test name" part is promoted to a first class concept, whereas the ruby binaries don't seem to care about the name.

In pact-js, we'll have to write something into the DSL that catches the test names and warns the user about repeat names

From my perspective, probably all I need right now is some more guidance about how the verifier handles work, unless we're planning to split those up into more fine-grained APIs soon. Even just docs on the functions would be fine for now (documenting what each arg does, which ones are exclusive, what happens if you specify 2 exclusive args, etc)

I'll follow the fluent API pattern in C#, and then I'll just have to store some stuff in memory and pass it all off to the FFI at the end I think, e.g. for that big options func

It'll be annoying if you do something weird though, because the error won't occur at the point where you expect it to

[I still like the idea of magic code based on rust introspection generating the interface]

I think you'd quickly end up with non-idiomatic code if you did that though. That's how Google do all their C# client libraries and they're _rubbish_

I think it depends on how you wrap it up, it looked promising on the python side at least to end up being able to generate the fluent interface, just depends on what you can do with the magic bit in the middle. Non-issue now anyway, I gave up with trying to progress it for python I think a miro board of some sort and bit of a GH project approach would be helpful somewhere, even to just be able to get an idea of what languages need to do what, and try and make sure feedback can be covered across them, if some proposed approach would be for some reason problematic in something

:thinking_face: re @pact544?s point on usage, would it help to have integration level reference implementation test examples, so the various languages could then perform those tests to get a better idea of overall compliance and behaviour?

Sorry, I have loads of questions about the FFI that I'm just not getting. First one - What's the difference between these things? Can I use them all at the same time? Provider tags is similar from the broker snippet, is that filtering by provider tags or setting provider tags for verification results?

I think filters is a method that is analogous to the `--filter-consumer` CLI option. It looks to take an array of strings The `consumer_version_selectors` is the newer way of specifying which contracts should come from the broker. It looks to accept an array of strings, each string being the same JSON shape that the CLI takes. `consumer_version_tags` is the old way of specifying the pacts to select, which only uses tagcs. I believe they can all be used simultaneously, albeit you usually would not want to use tags if you are using the other method. @tien.xuan.vo looks like a lot of these handles were via PR #145. Are you able to shed some light on them?

Apologies, today got away from me.

So is provider tags also a filter?

In this one, is this the name of the provider or the consumer? And I'm assuming `scheme` is a typo there, because it's parsed to `version`. Again, is that the consumer or provider version?

oh, `provider_tags` are about describing the current provider that is verifying the pacts, and is used in pending pacts calculations

i.e. consumer version selectars are about finding consumers that match a certain tag/branch/environment etc. provider tags (and related option like `provider_branch` ) are about communicating details about the provider. The pending status is calculated based on the details of the provider doing the verification

Oh, well then what does this do?

You can see my confusion right? :smile:

The terms all appear to be overloaded and it's often unclear which you should be using, and there's hardly any docs explainnig it

yes, it?s unclear to me too

I'll try to soldier on with the bit I can do. The internal state that's being built up is already huge though and I've not started the broker options yet :open_mouth:

It _looks_ like the `..with_selectors` method was the original all in one method, and then other more granular methods came along via the PR mentioned above.

~yes, I believe it is a typo/copy-pasta and should be version. I?d say it?s the provider name based on context~

oh, no!

That should be populated with `pact-net` and the version of the Pact .NET library. It will be used to emit anonymous usage metrics to GA (see #)

I'm working so I can't answer quickly. Yes, I created MR to add those missing ffi functions, but I'm same with you, still learning pact by create some simple merge requests, so I don't understand much. Here are something that I understand: ? `set_consumer_filters` filter pacts by consumer. I have an example here in PHP if you interested in https://github.com/pact-foundation/pact-reference/blob/master/php/src/provider.php#L41 ? `consumer_version_selectors` All I know it's a new way to filter pacts by consumer. There is a doc for it here https://docs.pact.io/pact_broker/advanced_topics/consumer_version_selectors/. I didn't use it yet. ? `consumer_version_tags` I don't know this, but Matt just said above it's just an old way to filter pacts ? `provider_tags` Also I don't know this one. This comment is from `Rust` code: `Tags to use when publishing results`

Oh! OK that wasn't clear at all. Cheers for that

We need to be able to disable those usage metrics as well then don't we? I don't see an option for that on the FFI

It can be disabled via an environment variable (it will actually print it out to users)

I don't know this one. It's new to me too. And I think you are right about typo. I think you can create merge request to fix it

```pact_do_not_track=true```

This makes it consistent across other languages (we currently support that in pact-node to track downloads)

I can confirm it's printed out. But I didn't try to disable it yet.

We really appreciate your enthusiasm and help so far Tien!

Gotcha

I just don't think this API makes sense. It forces you to specify the `provider_name` again, but you already had to supply that in the `set_provider_info` call (and in the PactNet code, you no longer have access to it because of the typestate pattern). It doesn't force you to set `provider_version` even though that's required for publishing results, and then `provider_version` is on a different func `set_verification_options` which you can call even if you aren't using a pact broker source, which would make no sense. If it's not intended to specify publishing options on this func, it's unclear why `provider_branch` and `provider_tags` are on there as those are publishing options. I'm having to try to tie my API code in knots to conform to that API whilst still making it usable and safe, which probably means other library maintainers will also. Is this the final API we're sticking with and we just need to get used to dealing with its quirks or are we planning on changing it to express its invariants properly?

And then this func doesn't make sense either. Some of those are applicable even if you aren't publishing results (like SSL verification and request timeout), but others only make sense if you are publishing results, like provider version and tags

In fact, the SSL and timeout options are applicable regardless of which source you're using, whereas the others only make sense if you're using a broker source

> Is this the final API we?re sticking with and we just need to get used to dealing with its quirks or are we planning on changing it to express its invariants properly? (edited) with this feedback, I can?t see us not wanting to change it, unless there is something I?m missing. Tien wrote it for Pact PHP, so may have some maintainer implementation advice

The only way I can see it working is if you keep one huuuge state object and then try to build it up as you go, then try to do all the FFI calls at the end. That's very error prone though, e.g. you could set both a file source and a URL source. At first count I was up to 26 parameters on the state object doing it that way, which just felt totally wrong

I've had to make a breaking change to PactNet to support this atm, and I can definitely see some more coming. e.g. request timeout and SSL verification could really do with being split from the publish options

Arghghgh all that and the logs still don't work

:worried: I did start trying to look at the logging, I wanted to get a bit of a baseline with some examples to compete between what happens currently Vs with ffi for the various languages, and what would be a good solution for all, e.g. logfiles Vs stderr, I think there are some differences between languages making that more complicated than one size fits all

Do you have any good (shareable) examples to figure out what's there now/used to be there/would like to be there?

I think I'm gonna try setting the log sink to write to file at the moment just to help me debug, but that's not really a good long-term solution because people do things like run tests in a Docker container with a read-only filesystem

OK, so I do get logs via the buffer, but only at TRACE level. There are no logs at DEBUG or higher... And there are no verification errors or anything like that either :disappointed:

Ah, all the calls inside the `pact_verifier` crate are just `println!` instead of `info!` or whatever, so they never end up going to the log buffer. They're just going to stdout, which is no good

And lots of the messages have ANSI colour code stuff in them, so it's not an easy find and replace of `println!` with info/log/etc either :disappointed: Well, still no logs for PactNet then!

When the Rust lib triggers the provider state endpoint, how come it's not providing a `Content-Length` or `Transfer-Encoding` header? .Net will reject all requests that don't do that, which is why my CI is currently failing

Here's the relevant CI logs, but it's getting back a HTTP 411 Length Required https://github.com/pact-foundation/pact-net/runs/4938617118?check_suite_focus=true#step:8:814

I've published a draft PR for moving to the new verifier handles approach here: https://github.com/pact-foundation/pact-net/pull/353 All the tests pass, but there's still a number of things that aren't supported, and some changes that I think need making to the FFI (unfortunately, breaking ones). I've documented some of them on the PR description.

I think one absolutely huge thing we need is a simple way to get back the nice friendly messages about the interactions that are running, their status and the overall mismatches summary you get at the end. At the moment there are two big problems with it: 1. They only go to stdout, and include ANSI colour code chars and stuff 2. They interleave with all the other log messages, so it's really hard to actually follow them Ideally the output would start with a section summarising what happened and what errors there were, and then the detailed logs of what it did would follow instead of interleave with them. That would make the DevEx really nice for when things go wrong, but also provide sufficient information to debug if it's not immediately obvious why you have errors (although in my experience it's almost always obvious once you see the mismatches)

i.e. I want what the CLI produces to come out first, and then the actual log messages (with the log level, file source etc) to come out separately instead of interleave

I was looking at structured logging to see if that could be a way to work well with different clients, then you can have more control over different types of logs and filter in ways other than just the level, but didn't get very far

The different levels was something Tim was keen to look at as mentioned ^

I like the idea of the formatting being exactly the same. The output from the CLI is a decent layout and the colours are good, and I wouldn't want different libraries to do it different ways. If that output was available via the FFI (hopefully with detecting whether the terminal supports colours or not) and not interleaved with the actual logging, that would be my ideal

Agreed about consistency

Thinking how you handle the different needs of stdout vs file The other use case Tim was talking about was there's trace level for a Pact user but potentially Trace for a maintainer might want visibility of more under the hood internals, which you might want to see separately/differently etc

I was thinking it could work if everything is a log, then client side you have control over yes print with normal log timestamps/prefix or not

hmm, strange. I can?t see why the http library used for that wouldn?t set those headers

I wonder if because we use a builder to construct the state change request and specify the headers, that it won?t automatically add the others: https://github.com/pact-foundation/pact-reference/blob/master/rust/pact_verifier/src/provider_client.rs#L84-L97

@uglyog any ideas?

Right, so yes, `println!` is never going to solve the problem you have. I think I saw a discussion elsewhere about getting a response from the verification process that contains fine grained assertion information (as is the case with the current Ruby version, with `--format json` enabled). This would be nice, especially if we could also add a standard output message to print that formats it the same across libraries. This would be separate to the logging output, which would then also solve log problem. What do you think about that? I think it would just be a matter of collecting all of the `println!` into a separate buffer, and in CLI mode just printing it out, and library mode returning the buffer (perhaps in a structured format, to allow for fine grained test output in due course)?

FYI it?s a public holiday here in Australia, so hence the relative quiet yesterday, today and possibly tomorrow

Yeah I think we need to really think about those 2 use cases. Users of the end client library (pact-net, pact-js, etc) first want a summary of the actual interactions and whether they passed or failed. Almost always, this is enough to know exactly what you need to do to fix it (e.g. the failure will say the response had a certain field, whereas the interaction expected another). I think this should be consistent across languages, and effort put in to make it really readable (I think the existing format isn't bad in that regard). They _may_ want some more fine-grained detail about what the library actually did, but probably not. As long as they know which URL was called and what the mismatch is, I think that's pretty much all you need. The other use case is for the library maintainers themselves, and probably really only the core/FFI maintainers. This will be for times when the interaction is passing/failing but it shouldn't be, and so the end-user can't fix it. This would indicate a bug in core/FFI and that's when we'd need the more detailed logs. From typing that, I think I've convinced myself that those logs shouldn't be 'on by default', and instead it's the type of thing where we'd request further info in a bug report (like "please enable this flag and then send the output"). I also think the end-user logs shouldn't have things like timestamps, file sources, log levels etc. etc. on them. The output of that needs to be really clean and readable, and all of those things are just noise that the end-user doesn't really care about.

Tried this out locally in PactNet and it works really nicely :+1:

It appears to only happen when you use the provider states in the query string instead of the body. It's still a `POST` but that should have an accompanying `Content-Length: 0` header

Turns out it's the name and version of the library itself (not provider or consumer). I've fixed it in https://github.com/pact-foundation/pact-reference/pull/173

ah, interesting!

could be a bug in reqwest

Speaking of: https://github.com/seanmonstar/reqwest/pull/1316#issuecomment-1020499420

Came back to a full inbox, mostly of which is Adam/Pact .NET today - did you fix that issue in the Rust PR?

Yeah I've raised a couple of FFI PRs and done the PactNet mods locally to use them. They're a nice ergonomic improvement there :+1:

I think I?m in agreement with that. Tim had a point that if we buffer logs in the FFI directly and it panics, then we are cooked for debug data, but I think the general UX where all data is buffered and the client can choose how/when to print makes the most sense

oh, that?s awesome. Thank you

I was going to share the starting point sheet I looked at but I just checked and it's not very helpful for explanation anyway :joy: What I was thinking was to try and do a crude side by side across the different languages of how log output typically looks, and "end users want to see a normally, end users want to see b with debug, maintainers want to see c normally, maintainers way to see d with debug", vs what currently happens

There?s a lot happening in Pactflow town at the moment, hopefully Ron can take a look in the next couple of days. Will the change require changes for @tien.xuan.vo ?

yep, that makes sense

we want each language to be as idiomatic as possible. .NET is definitely a blind spot for a few core maintainers, so having Adam/Yann advocate and be part is very helpful

as always happens I think when I started to look, first there were problems with me trying JS (which Tim nicely fixed but I'd run out of time) followed by as I was looking at logs I noticed a FFI bug of sending the provider state destroy when it shouldn't be so I did that instead :joy: tangents!

yep. the maintainers wanting to see x going into a log file rather than a buffer because panic is a good one

I think so yes, it's a breaking change in the FFI. We may want some more in future, but those are 2 obvious ones which are blockers for PactNet

[one day I will try and get past just talking about things and actually get onto doing them]

With reqwest we might need to set an empty body. I'll have a look into that.

@pact544 I've merged the PRs. I'm going to look at extracting the verification output (this will be separate from the logging), but I will leave the printing it out to stdout because it works nicely in other languages.

I will also bump the minor version (to 0.2.0) due to the breaking changes

If it helps, I?m happy to have the stdout logs buffered for Pact JS/Go and control the output programmatically (but separately) to the other logs. But yes, printing to stdout is not currently causing issues for them.

Yeah if it prints to stdout also then I think that's gonna cause problems in places like GitHub Actions. That does seem to capture stdout (whereas running locally doesn't) so if it still printed to stdout you'd get all the output twice :open_mouth:

It'd be cool if it could auto-detect whether the terminal was capable of colours or nt as well, and still include the ANSI codes because that's def useful. Or if it can't detect, perhaps provide a flag to force colour on or off so that user's can set it appropriately

The new verifier handles feature behaves differently on different OSs: https://github.com/pact-foundation/pact-net/runs/4964627047?check_suite_focus=true I've written an integration test just to make sure the external bindings work, but it never starts an actual provider API so obviously it should fail (and the test checks that the verification fails). On Windows and Linux that's exactly what it does, but on OSX the verifier tests pass :open_mouth: They can't possibly pass though, because there's no provider running and I've pointed at pact sources that don't even exist (like `http://broker.example.org`). The test also takes 58s to run even though I've set a request timeout of 100ms

Raised as https://github.com/pact-foundation/pact-reference/issues/176

FYI - looks like soon the certificate problem with tls-native will be solved in reqwest: https://github.com/seanmonstar/reqwest/pull/1316

Good news :+1: Currently I can't run a single provider test on my machine :D

time to get rid of those 10 year old self-signed certs Adam :laughing:

Just whatever AD is pushing onto my machine I guess :shrug: Or whatever http://ASP.Net dev certs get generated

I've created a JSON schema to describe the verification results JSON :point_right: https://github.com/pact-foundation/pact-reference/blob/master/rust/pact_verifier/src/verifier-results.schema.json

You might want to put a `v1` in there or something just in case it changes in future

I've tried using the new `pactffi_verifier_output` method and unfortunately ~I just get an empty string from it~ the output is all screwed up by the ANSI colour codes :disappointed: I could only get it to work by running inside a Linux container because of the blocker thing about invalid certs on my machine, but the output just looks like this:

Another problem with that output is that it never shows you the actual response body. For example, consider this output. That doesn't help me in finding out where the problem is because I can't see the actual response body. I tried looking in the logs also and it's not printed there either, it just says "Present" ``` [INFO][pact_verifier::provider_client] Received response: HTTP Response ( status: 200, headers: Some({"date": ["Wed", "02 Feb 2022 08:49:28 GMT"], "server": ["Kestrel"], "transfer-encoding": ["chunked"], "content-type": ["application/json; charset=utf-8"]}), body: Present(356 bytes, application/json;charset=utf-8) )``` The Ruby version outputs the entire message when any interactions fails so you can spot what went wrong.

I've got this working locally by using the default native TLS support in reqwset. Is there any reason we're using rustls instead? This seems to work much better:

Unless something has changed, last I checked, the default wasn?t clever enough to discover your self-signed certificates. We moved so that it would respect the standard openssl env vars (`SSL_CERT_FILE` etc.)

yeah: https://github.com/pact-foundation/pact-reference/issues/144

we definitely do want that. I wonder if it?s hidden away in a DEBUG/TRACE level log? It could be made to be printable, I?m sure

I just can't fix this ANSI code thing. I knew that was gonna be a problem. If you feed strings with ANSI codes in them through xUnit then they don't apply when they end up on the actual test output. If I write directly to the console they do (after some kernel calls to enable VT mode on the terminal :open_mouth:), but not via xUnit. At the moment I've literally had to just strip them out with a regex

I'll add an option to disable the ANSI control codes

Are you still having issues getting the logs? The request/response details won't be in the console output. I can clean those up, but it won't help if you can't get the logs.

Hmm, good point.

Bodies were being logged at trace level. I will change that to debug level.

I've released 0.2.1 with the following changes: ? req/res bodies are logged at debug level ? `enable_ansi_support` has moved out of `pactffi_init` into a new function `pactffi_enable_ansi_support` ? `pactffi_verifier_output` now has a second parameter `strip_ansi`. If non-zero, the ANSI control codes will be stripped.

what?s the use case for having `pactffi_enable_ansi_support` and the ability to strip them off in the verifier output?

Trying to cover all the bases. I'm assuming if `pactffi_enable_ansi_support` is not called, there won't be ANSI codes in the output, but in case there are still, then ....

So ANSI support is disabled by default and you need to explicitly enable it?

On Windows, yes

Question about message pacts - at the moment PactNet writes the pact file (in merge mode) after verifying each interaction, but that seems wasteful. I can't remember why it's done that way though - is it necessary/recommended via the FFI or should the pact file just be written once? I know for request pacts it's necessary because the mock server can only be configured once per verification, but I can't think of a reason why message pacts have that restriction

I can?t remember myself

Yeah I feel like I can make one message pact handle, but lots of message handles, and then just write the pact file once at the end. I suppose it's a bit theoretical though. Even if you write the file 100 times in merge mode it's not exactly gonna destroy performance, it just irks that it's inefficient :joy:

haha yes. It?s plausible to do it that way, I?d need to look at the interface again

Maybe we did it because it was easier to port existing implementations over?

@tjones has left the channel

With Pact-JVM, some people create a separate test for each interaction. I've seen one with 12 interactions, each a separate test. In that case, it has to merge otherwise they will overwrite each other

Yeah, we do a separate test for each interaction also. The question was more about whether you need to write the pact after each interaction or not, i.e. do I need to do this: ? Create pact handle ? Create message handle ? Verify ? Write pact file ? GOTO 1 or this: ? Create pact handle ? Create message handle ? Verify ? Create message handle ? Verify ? Create message handle ? Verify ? Write pact file

Question on the new `pactffi_verifier_*` functions - the `VerifierHandle` appears to be a struct, unlike the other consumer handles which are essentially opaque numbers. Was there a reason this was not done in a similar way?

Do I need to create an issue for this?

Yes, otherwise it will be forgotten

Here is the issue https://github.com/pact-foundation/pact-plugins/issues/2

Looking at adding message pact into the v3 branch of Pact JS. I can see a number of methods that deal with `MessagePactHandle` e.g. (`pactffi_new_message_pact`) and others that use `PactHandle` and `MessageHandle` (e.g. `pactffi_new_async_message`) I?m assuming the latter are to do with v4 pacts where they can be attached, and the former v3?

Hopefully the PactNet implementation could shed some light on that? MessagePactHandle definitely represents the entire pact, whereas MessageHandle is just an individual interaction, but yeah I don't get why PactHandle has got involved there. Perhaps it's a typo but it just work anyway, given they're essentially the same two objects and they're just integer IDs basically

Thanks, I should check the underlying implementation but looking at the C headers it's hard to see which ones to use and why

The original PR introduced the V3 message Pact, so that might be causing the confusion. `PactHandle` represents the Pact file (whether V3 or V4). `MessagePactHandle` is a V3 message Pact. `MessageHandle` is an interaction.

Cool thx. So I should use the new ones then on the Pacthandle?

Yes

I?m still a little confused. I can see that the async methods still return a `MessageHandle` (so the related message functions are still available) but the `pactffi_new_sync_message_interaction` returns an `InteractionHandle` which seems strange to me because the methods that operate on that are HTTP centric. I can?t see how you would set the request/response components of that?

Ditto `pactffi_new_message_interaction` .

:thread: Thread on plugins :point_down:

First go (spiking Golang) - it works with standard HTTP request/response :tada:

I was thinking how the gRPC plugin would work with the current protobufs one. I?m assuming that `pactffi_interaction_contents` is the interface for a content type plugin, and we?d add a new ffi interface for a transport plugin? i.e. you would want to use these things together, but I can?t see how this interface would support something like gRPC. If that?s the case, then the current PactHandle methods aren?t going to look very sensible. ``` i.UponReceiving("some interaction"). Given("plugin state"). WithRequest("GET", "/protobuf"). WithStatus(200). WithPluginInteractionContents(INTERACTION_PART_RESPONSE, "application/protobuf", protobufInteraction)``` That?s the example Golang plugin test I ran before which worked :ok_hand: But assuming that gRPC would have a separate interface, e.g. `pactffi_plugin_transport` or something? ``` i.UponReceiving("some grpc interaction"). Given("plugin state"). WithPluginTransport("grpc", <some json configuration object?>) WithPluginInteractionContents(INTERACTION_PART_RESPONSE, "application/protobuf", protobufInteraction)```

How do you add metadata to the new message interface on the `PactHandle` that return `InteractionHandle` ? i.e. I?m looking for the replacement for `pactffi_message_with_metadata` on `MessageHandle`

The Java ans Rust ones work by configuring the interaction as current, then start a mock server from that. The mock server updates the interaction to use a gRPC transport.

So how would I signal to the mock server that it should be a gRPC one, I guess. Is there going to be a new FFI method or is simply adding the plugin enough for the mock server to convert to a gRPC transport?

I haven't got to the FFI interface yet

One of the primary reasons I?m asking is because I?m trying to figure out what the next iteration of the DSL looks like to JS/Golang. I?ve got some feedback on a builder/type-state DSL, but I think the plugin interface is going to significantly impact that design. Ideally I just do it once. In JS, we added a very JSON-like interface: ```{ state: 'i have a list of projects', uponReceiving: 'a request for projects', withRequest: { method: HTTPMethods.GET, path: '/projects', headers: { Accept: 'application/json' }, }, willRespondWith: { status: 200, headers: { 'Content-Type': 'application/json' }, body: {}, }, };``` This makes it super easy to convert other JSON structures to a Pact interaction. But you can see how the validation on this sort of structure would get super messy with plugins (and indeed, some of the features in v3). I?ll probably preserve it for HTTP pact, but I?d like a more type safe API going forward if possible. e.g. you shouldn?t be able to add an HTTP header to a message pact. Or, if using a different transport, you shouldn?t be configuring other things on the HTTP mock server

has joined #libpact_ffi-users

has joined #libpact_ffi-users

has joined #libpact_ffi-users

I've just raised a new FFI issue for a breaking change: https://github.com/pact-foundation/pact-reference/issues/196 I think it's really important as we want more and more libraries to be shipping on top of the FFI to have a really good regression test suite at the 'black box' level (i.e. using the FFI library itself from another language) and also to communicate breaking changes really clearly with maintainers. There has been no discussion on this channel about the change beforehand, no impact assessment/statement, no guidance on what to look out for afterwards, and I think we need to fix that. I think we need a more mature process around evolving the FFI and maintainers need to be a big part of that discussion. I just happened to notice that it had made logging unusable, and people are going to come to rely on that because they can't just set a breakpoint in their code or whatever, because it now all crosses an FFI boundary. This is the type of thing we need to discuss beforehand so that maintainers are aware they need to check things after upgrades, and ideally this should be found long before the FFI is released and people start upgrading to it. The big problem with the FFI approach is that the bugs will ultimately be reported at the client library level instead of in `pact-reference` itself. If I would've missed that and shipped it, the bug reports would've been raised against PactNet, even though nothing in PactNet changed and the fix doesn't need to be made to PactNet. This hurts the reputation of PactNet, me personally, and the pact ecosystem as a whole, despite it being something generally outside of my control. I apologise that that's a bit of a rant, but it's very frustrating to be surprised like that and I think we need to define an approach going forwards which prevents those surprises.

Probably one for @yousafn

Really fair comments @pact544 - Rants are welcome, it is a safe space here. We do need to and have a duty to make sure the developer experience is on point for maintainers, as it can have direct and very real impact on end users who are using our libraries to protect their deployments. Appreciate your eagle eye, and I also noted an issue you raised against the pact-specification today aswell. Will take some time to digest, discuss and get something open arranged for us to attend, collect thoughts, agree a path forward. Apologies for the inconvenience!

There are actually a number of tests/examples for the FFI interface (including some c tests e.g. https://github.com/pact-foundation/pact-reference/blob/master/rust/pact_ffi/examples/logging/src/main.c). But I think this behaviour is not included in that. I think it would be a good opportunity to revisit the test strategy here. We have discussed the idea of a BDD suite here that shows what the FFI does (ideally, there is also a standard client BDD test suite we have also that can be used to test each language. This could also work as a nice up-to-date feature matrix table)

has joined #libpact_ffi-users

has joined #libpact_ffi-users

@pact544 can you please stay on the 0.2.x version. I'll let you know when 0.3.x is ok to use

(+1 for structured logging! :slightly_smiling_face:)

I don't think structured logging solves the problem, because then that just pushes the problem of parsing and displaying it onto every client library. We want a consistent report in all the client libraries, and our method for that is to do it in the shared FFI. I can't stress enough how important these logs are. I've just migrated a codebase with 2283 consumer tests, where 68 were falling after the upgrade. I had to use the logs extensively because there are a number of breaking changes to track down, and the logs are the only place that give you the info you need to work that out. In my case, most of the failures were because the Ruby library doesn't validate query string parameters whereas the Rust library does. We had a few tests where the client sends a query parameter but the setup didn't include it, so now those tests fail. The logs are the **only** way you can find that out.

:disappointed: I'm not quite sure where the last year went, I still have on my to-do list progressing looking at how the different libraries get logs and what they look like for useful filtering etc following a conversation with Tim I will actually get time at some point :open_mouth:I struggled a bit with the overhead of getting a similar example for each language to get anything meaningful Getting a bit closer :wave: @yousafn :grinning:

We might want to find a way to open this discussion up and maybe get some face time together. There appears to be a few collaborators who are existing maintainers, long time contributors, or new contributors who are getting involved in different parts of the estate and would be good to get a round table. I can see some work @lewiscowles has been doing across various repos, so is offering fresh insight with some sensible ideas for long term maintainence which are worth surfacing somewhere. I know this is diverging slightly from the actual logging issue but might allow us to take a wider lense view of the estate as a whole. Just spitballing ? agree on a central place to collab ? Drop in sessions across different tz?s to allow video communication as well as async communication proper Diagram of the dependency graph of doom ? target state ? Gap analysis Definitely worth getting the input and thoughts of other maintainers, contributors and users here as there will be such valuable insight and potential actionable items, that I can help coordinate

Associated pact-php consumption of ffi thread here https://pact-foundation.slack.com/archives/C9W94PXPY/p1653476185980649 We can save all the prior discussions from this and other conversations/issues over the months/years and move them as they are a bit scattered and reducing context/platform switching or providing a single index is probably key to focusing our cognitive load towards common goals

@matt.fellows @uglyog We were having a discussion about publishing verification results when using non-broker sources https://pact-foundation.slack.com/archives/C9UTHV2AD/p1653469545842399. Someone had asked because the https://docs.pact.io/pact_nirvana recommend that a verification job be invoked with a changed pact URI (linked to the broker), which you then verify via a URL source (not a broker source) and publish the verification results back. The user was surprised that PactNet didn't support this option, but in the thread I explained that you can't publish verification results because you don't know the broker URL (and potentially credentials also). I raised https://github.com/pact-foundation/pact-net/issues/392 and I've already pushed up a draft MR for it, but unfortunately at the moment it can't progress. I've checked the FFI and it doesn't support publishing verification results for anything other than broker sources: https://github.com/pact-foundation/pact-reference/blob/e32caf8defd399029dcdf09c5d9298a1fe71d75a/rust/pact_verifier/src/lib.rs#L1207-L1228 If I call `set_publish_options` on the FFI and add anything other than a broker source then it'll simply not publish anything and log an error instead.

So I think the only safe/robust thing to do if we want to support this (and given the CI/CD guide says it's the recommended way of doing it...) is that the user is forced to specify the broker URL in the publish options at the FFI boundary. We can design nicer library APIs on top of that, but fundamentally you can't just assume the host of the URI is also the host of the broker.

e.g. the broker could be running on a sub-path instead of a dedicated sub-domain, like `https://ci.example.org/broker` , so you can't just extract the host and reuse that. It'd also be very hacky to use some kind of fixed string in the path and take everything up to that path. Pact broker URLs always have `/pacts/` in them somewhere, but you can't just assume that's the only place that'll be. Again, someone could run their broker at `https://ci.example.org/pacts` and now string splitting is just asking for trouble.

What do we need to do to resolve these issues? One thing I have been thinking of is splitting out the FFI into it's own repository. That way we could hand it over to this group to manage, and I can step away to focus on other areas. The plugin and gRPC work is now nearly complete (which is what I have been focusing on the last 6 months). I just need to get an example project working via FFI (hence the recent change which required a new function), then there are no more plans to change anything else.

I have answered on the issue.

has joined #libpact_ffi-users

Hello. I don't know if this is the correct venue to ask for help but here we go. I am using `pact-go` and when running the provider verification I am noticing that the test hangs after the call to `libpact_ffi`. ```2022/06/02 13:09:55 [INFO] package libpact_ffi found 2022/06/02 13:09:55 [INFO] checking version 0.3.3 for lib libpact_ffi within semver range >= 0.1.2, < 1.0.0 2022/06/02 13:09:55 [INFO] checking version 0.3.3 of libpact_ffi against semver constraint >= 0.1.2, < 1.0.0 2022/06/02 13:09:55 [DEBUG] 0.3.3 satisfies constraints 0.3.3 >= 0.1.2, < 1.0.0 2022/06/02 13:09:55 [DEBUG] version check completed 2022/06/02 13:10:21 [DEBUG] starting new proxy with opts {http localhost:8080 0 [0x1036d5910] /__setup <nil>} 2022/06/02 13:10:21 [DEBUG] starting reverse proxy on port 49359 2022/06/02 13:10:21 [DEBUG] waiting for port 49359 to become available 2022/06/02 13:10:21 [DEBUG] pact provider verification 2022/06/02 13:10:21 [DEBUG] initialising rust mock server interface 2022/06/02 13:10:22 [DEBUG] waiting for port 49359 to become available 2022/06/02 13:10:24 [DEBUG] executing verifier FFI with args [--file /Users/nunofrias/Documents/repos/entitlement-orchestrator/cmd/pacts/reseller-entitlement-service-entitlement-orchestrator.json --hostname localhost --port 49359 --provider-name entitlement-orchestrator --loglevel trace] Hangs here !``` I proceeded to debug the rust ffi code and found that the exact point where it hangs is in the `make_provider_request` function in `http://provider_client.rs` , more precisely in: ```let response = request.send() .map_err(|err| anyhow!(err)) .and_then(native_response_to_pact_response) .await?;``` More curiously I have also noticed that the first time I run the provider verification after I start the terminal application, it succeeds. Subsequent verifications fails more often than not -- if I restart the command line the verification succeeds. I would dearly appreciate some help as my knowledge of rust is rather basic. Thank you.

Hi Nuno, thanks for diving into this

what would be great to know: ? Does it only do this on certain OS?s (e.g. Mac but not linux)? ? Which version of Pact Go are you running

The ?it works once? makes me wonder if any processes are up and about. For example, when it hangs above, can you send http calls to the provider? eg. `curl localhost:49359` or to the proxied target (the actual provider)?

Hi Matt I am using `go version go1.17.6 darwin/arm64` I am running on Mac OS 12 (and it is an M1 chip) I suspect there are some processes outstanding. I am about to enable `dtruss` (strace equivalent) to try and pinpoint the error.

I can send calls to `localhost:49359` and I see the server responses.

Thanks! What version of pact go?

`v2.0.0-beta.11`

I am using the `v2.x.x` branch.

:thinking_face:

have you got a github actions / some build we can see running that reproduces the issue? Does it only happen on M1 (FYI I?m running an M1)

I don't have a build you can test. What I can do is actually run the examples on pact-go and see if the problem occurs. I'll try on Linux (raspberry py) to see if I can see the issue there.

On it

I managed to reproduce it with the examples in Pact go. I am sending a patch file with some very minor changes to the default examples namely to the provider test. Essentially I am commenting out the ProviderVersion BrokerURL ConsumerVersionSelectors PublishVerificationResults as I am using a local pact file and to simplify this scenario I am bypassing the communication with the broker. I also comment out the StateHandlers bit as it caused the test to hang on the state change rather than on running the actual provider request -- the underlying issue seems identical. To set up the example you only need to: ``` git checkout 2.x.x git pull git apply pact_go_examples.diff cd pact-go/examples go test -run ^TestConsumerV3$ . go test -tags provider -run ^TestV3HTTPProvider$``` I am still working on setting up the GitHub actions (but let me know if the above suffices).

has joined #libpact_ffi-users

I should have a github action ready briefly.

Here it is. This project contains a minimal example. Apologies for taking this long, I am not used to github actions. https://github.com/nsfrias/pact-go-issue-repro-20220607

As of now I am still waiting for the results of the `macos-12` (which I hope behave similarly to my Mac). https://github.com/nsfrias/pact-go-issue-repro-20220607/actions/runs/2456922279

In ubuntu the issue does not occur.

Thanks Nuno. I can see that it worked on linux too, but the mac build is hanging :man-shrugging:

I am having difficulty running the build against even a x86 macos https://github.com/nsfrias/pact-go-issue-repro-20220607/runs/6793692978?check_suite_focus=true Would it be possible for you to install the project locally on an M1 platform and run the test?

I added some manual reproduction steps on the README

has joined #libpact_ffi-users

```? /tmp git clone https://github.com/nsfrias/pact-go-issue-repro-20220607.git Cloning into 'pact-go-issue-repro-20220607'... remote: Enumerating objects: 63, done. remote: Counting objects: 100% (63/63), done. remote: Compressing objects: 100% (31/31), done. remote: Total 63 (delta 22), reused 48 (delta 11), pack-reused 0 Receiving objects: 100% (63/63), 26.85 KiB | 8.95 MiB/s, done. Resolving deltas: 100% (22/22), done. ? /tmp cd pact-go-issue-repro-20220607 ? pact-go-issue-repro-20220607 git:(main) go install http://github.com/pact-foundation/pact-go/v2@2.x.x go: downloading http://github.com/pact-foundation/pact-go/v2 v2.0.0-beta.11.0.20220607035712-b017cad30d3d ? pact-go-issue-repro-20220607 git:(main) pact-go -l DEBUG install 2022/06/09 15:54:22 [INFO] package libpact_ffi found 2022/06/09 15:54:22 [INFO] checking version 0.3.2 of libpact_ffi against semver constraint >= 0.3.0, < 1.0.0 2022/06/09 15:54:22 [DEBUG] 0.3.2 satisfies constraints 0.3.2 >= 0.3.0, < 1.0.0 2022/06/09 15:54:22 [INFO] package libpact_ffi is correctly installed 2022/06/09 15:54:22 [DEBUG] skip checking ffi version() call because FFI not loaded. This is expected when running the 'pact-go' command. ? pact-go-issue-repro-20220607 git:(main) go test -run "^TestConsumerV3$" consumer_test.go go: downloading github.com/stretchr/testify v1.7.2 go: downloading github.com/golang/protobuf v1.3.3 ok command-line-arguments 0.846s ? pact-go-issue-repro-20220607 git:(main) go test -timeout 30s -run "^TestV3HTTPProvider$" . ok example.com/m 3.618s ? pact-go-issue-repro-20220607 git:(main) go test -v -timeout 30s -run "^TestV3HTTPProvider$" . === RUN TestV3HTTPProvider 2022/06/09 15:55:26 [INFO] package libpact_ffi found 2022/06/09 15:55:26 [INFO] checking version 0.3.2 for lib libpact_ffi within semver range >= 0.1.2, < 1.0.0 2022/06/09 15:55:26 [INFO] checking version 0.3.2 of libpact_ffi against semver constraint >= 0.1.2, < 1.0.0 2022/06/09 15:55:26 [DEBUG] 0.3.2 satisfies constraints 0.3.2 >= 0.1.2, < 1.0.0 2022/06/09 15:55:26 [DEBUG] version check completed 2022/06/09 15:55:26 [DEBUG] starting new proxy with opts {http localhost:8111 0 [0x4390e60 0x4391160 0x461c1c0] /__setup <nil>} 2022/06/09 15:55:26 [DEBUG] starting reverse proxy on port 64647 2022/06/09 15:55:26 [DEBUG] waiting for port 64647 to become available 2022/06/09 15:55:26 [DEBUG] pact provider verification 2022/06/09 15:55:26 [DEBUG] initialising rust mock server interface 2022/06/09 15:55:26 [DEBUG] waiting for port 64647 to become available 2022/06/09 15:55:26 [DEBUG] executing verifier FFI with args [--file /tmp/pact-go-issue-repro-20220607/pacts/PactGoV3Consumer-V3Provider.json --hostname localhost --port 64647 --provider-name V3Provider --loglevel trace] Given User foo exists WARNING: State Change ignored as there is no state change URL provided 2022/06/09 15:55:28 [DEBUG] HOOK request filter 2022/06/09 15:55:28 [DEBUG] http reverse proxy received connection from [::1]:64653 on path /foobar?baz=bar&baz=bat&baz=baz 2022/06/09 15:55:28 [DEBUG] setting proxy to target 2022/06/09 15:55:28 [DEBUG] incoming request /foobar?baz=bar&baz=bat&baz=baz 2022/06/09 15:55:28 [DEBUG] outgoing request to target http://localhost:8111/foobar?baz=bar&baz=bat&baz=baz 2022/06/09 15:55:28 [TRACE] proxy outgoing request POST /foobar?baz=bar&baz=bat&baz=baz HTTP/1.1 Host: localhost:8111 User-Agent: Pact Go Content-Length: 76 Accept: */* Accept-Encoding: gzip, deflate Authorization: Bearer 1234 Authorization: Bearer 1234-dynamic-value Content-Type: application/json X-Forwarded-For: ::1 2022/06/09 15:55:28 [TRACE] proxied server response HTTP/1.1 200 OK Content-Length: 458 Content-Type: application/json Date: Thu, 09 Jun 2022 05:55:28 GMT { "accountBalance": 123.76, "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", "arrayContaining": [ "string", 1, { "foo": "bar" } ] } 2022/06/09 15:55:28 [DEBUG] executing after hook 2022/06/09 15:55:28 [DEBUG] HOOK after each Given User foo exists WARNING: State Change ignored as there is no state change URL provided 2022/06/09 15:55:28 [DEBUG] HOOK request filter 2022/06/09 15:55:28 [DEBUG] http reverse proxy received connection from [::1]:64656 on path /foobar?baz=bar&baz=bat&baz=baz 2022/06/09 15:55:28 [DEBUG] setting proxy to target 2022/06/09 15:55:28 [DEBUG] incoming request /foobar?baz=bar&baz=bat&baz=baz 2022/06/09 15:55:28 [DEBUG] outgoing request to target http://localhost:8111/foobar?baz=bar&baz=bat&baz=baz 2022/06/09 15:55:28 [TRACE] proxy outgoing request POST /foobar?baz=bar&baz=bat&baz=baz HTTP/1.1 Host: localhost:8111 User-Agent: Pact Go Content-Length: 76 Accept: */* Accept-Encoding: gzip, deflate Authorization: Bearer 1234 Authorization: Bearer 1234-dynamic-value Content-Type: application/json X-Forwarded-For: ::1 2022/06/09 15:55:28 [TRACE] proxied server response HTTP/1.1 200 OK Content-Length: 458 Content-Type: application/json Date: Thu, 09 Jun 2022 05:55:28 GMT { "accountBalance": 123.76, "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", "arrayContaining": [ "string", 1, { "foo": "bar" } ] } 2022/06/09 15:55:28 [DEBUG] executing after hook 2022/06/09 15:55:28 [DEBUG] HOOK after each Given User foo exists WARNING: State Change ignored as there is no state change URL provided 2022/06/09 15:55:29 [DEBUG] HOOK request filter 2022/06/09 15:55:29 [DEBUG] http reverse proxy received connection from [::1]:64659 on path /foobar?baz=bar&baz=bat&baz=baz 2022/06/09 15:55:29 [DEBUG] setting proxy to target 2022/06/09 15:55:29 [DEBUG] incoming request /foobar?baz=bar&baz=bat&baz=baz 2022/06/09 15:55:29 [DEBUG] outgoing request to target http://localhost:8111/foobar?baz=bar&baz=bat&baz=baz 2022/06/09 15:55:29 [TRACE] proxy outgoing request POST /foobar?baz=bar&baz=bat&baz=baz HTTP/1.1 Host: localhost:8111 User-Agent: Pact Go Content-Length: 76 Accept: */* Accept-Encoding: gzip, deflate Authorization: Bearer 1234 Authorization: Bearer 1234-dynamic-value Content-Type: application/json X-Forwarded-For: ::1 2022/06/09 15:55:29 [TRACE] proxied server response HTTP/1.1 200 OK Content-Length: 458 Content-Type: application/json Date: Thu, 09 Jun 2022 05:55:29 GMT { "accountBalance": 123.76, "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", "arrayContaining": [ "string", 1, { "foo": "bar" } ] } 2022/06/09 15:55:29 [DEBUG] executing after hook 2022/06/09 15:55:29 [DEBUG] HOOK after each Verifying a pact between PactGoV3Consumer and V3Provider 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 (OK) Verifying a pact between PactGoV3Consumer and V3Provider 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 (OK) Verifying a pact between V3Consumer and V3Provider 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 (OK) === RUN TestV3HTTPProvider/Provider_pact_verification --- PASS: TestV3HTTPProvider (3.10s) --- PASS: TestV3HTTPProvider/Provider_pact_verification (0.00s) PASS ok http://example.com/m 3.663s```

output from `go env`: ``` GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/Users/matthew.fellows/Library/Caches/go-build" GOENV="/Users/matthew.fellows/Library/Application Support/go/env" GOEXE="" GOEXPERIMENT="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GOINSECURE="" GOMODCACHE="/Users/matthew.fellows/go/pkg/mod" GONOPROXY="" GONOSUMDB="" GOOS="darwin" GOPATH="/Users/matthew.fellows/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/local/Cellar/go/1.18.2/libexec" GOSUMDB="http://sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/Cellar/go/1.18.2/libexec/pkg/tool/darwin_amd64" GOVCS="" GOVERSION="go1.18.2" GCCGO="gccgo" GOAMD64="v1" AR="ar" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="/tmp/pact-go-issue-repro-20220607/go.mod" GOWORK="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/gl/c3f3yhws1mg754r_t7l5hfm80000gp/T/go-build2365344512=/tmp/go-build -gno-record-gcc-switches -fno-common"```

Thank you very much

I still encounter the same issue, so does a colleague with M1.

The only difference is the `go env`

Are you running in Rosetta mode or normal? Have you tried both?

Are they work machines or personal? Is it possible there is AV or endpoint security interference?

I am running in normal mode. I have had some issues with rosetta in the past.

Work machines

I wish we could run builds on M1 to create a reproducible environment. Unfortunately there are no real options to do so at the moment

I am trying to run in rosetta mode

That said I manage to workaround the issue by running the tests on a linux VM running on my mac

Btw I add to add another `cgo` config to run pact-go in linux arm64. ```diff --git a/internal/native/lib.go b/internal/native/lib.go index 9ece6b7..d4324ff 100644 --- a/internal/native/lib.go +++ b/internal/native/lib.go @@ -6,5 +6,6 @@ package native #cgo darwin,amd64 LDFLAGS: -L/tmp -L/usr/local/lib -Wl,-rpath -Wl,/tmp -Wl,-rpath -Wl,/usr/local/lib -lpact_ffi #cgo windows,amd64 LDFLAGS: -lpact_ffi #cgo linux,amd64 LDFLAGS: -L/tmp -L/opt/pact/lib -L/usr/local/lib -Wl,-rpath -Wl,/opt/pact/lib -Wl,-rpath -Wl,/tmp -Wl,-rpath -Wl,/usr/local/lib -lpact_ffi +#cgo linux,arm64 LDFLAGS: -L/tmp -L/opt/pact/lib -L/usr/local/lib -Wl,-rpath -Wl,/opt/pact/lib -Wl,-rpath -Wl,/tmp -Wl,-rpath -Wl,/usr/local/lib -lpact_ffi */ import "C"```

Will submit a merge request for that asap

Does it work on Linux arm? I don't think it should, to my knowledge we don't compile for it: https://github.com/pact-foundation/pact-reference/releases/tag/libpact_ffi-v0.3.2

I compiled for it locally

Ah, got it.

Fair enough we can definitely bring that in

I feel sheepish now. I gave it a try with rosetta and it is passing consistently.

Thank you very much for all the help.

But it should be able to work outside of Rosetta. That's a good clue though. I should be able to repro that situation

has joined #libpact_ffi-users

has joined #libpact_ffi-users

has joined #libpact_ffi-users

has joined #libpact_ffi-users

has joined #libpact_ffi-users

I got one problem with pact plugins: When I verify provider's pacts that required plugins (csv, protobuf), on Linux and Mac, it work fine, but on Windows it hang. It happen on this line https://github.com/tienvx/pact-php/blob/rust-ffi-plugins-downloads/src/PhpPact/Standalone/ProviderVerifier/Verifier.php#L163 As you can see here https://github.com/tienvx/pact-php/actions/runs/3099040342 , all tests *passed* on Linux and Mac. On Windows it *hang* for hours. I have to cancel it manually. Version: ? pact-ffi: 0.3.11 ? pact-csv-plugin: 0.0.3 ? pact-protobuf-plugin: 0.1.13 Pacts: https://github.com/tienvx/pact-php/tree/rust-ffi-plugins-downloads/example/pacts I test again on my Windows machine and the same behavior:

I have this same problem, and I haven't found the answer to the issue. Can you raise an issue for this?

Sure. I will report to pact-plugins repo

has joined #libpact_ffi-users

has joined #libpact_ffi-users

I saw a inconsistency in file naming: ? https://github.com/pact-foundation/pact-reference/releases/download/libpact_ffi-v0.3.15/libpact_ffi-linux-x86_64.so.gz ? https://github.com/pact-foundation/pact-reference/releases/download/libpact_ffi-v0.3.15/libpact_ffi-osx-x86_64.dylib.gz ? https://github.com/pact-foundation/pact-reference/releases/download/libpact_ffi-v0.3.15/pact_ffi-windows-x86_64.dll.gz `libpact_ffi` vs `pact_ffi` . I think there is a typo somewhere? But I guess we don't want to fix it because currently there are many languages are downloading and using these files?

Windows has a different convention. For Linux, the .so file has to start with lib otherwise it won't be automatically picked up, I assume OSX is the same.

has joined #libpact_ffi-users

:wave::skin-tone-4: all - i'm helping a dev with a failed build relating to a pact test. nothing seems to have changed on our end but got a `dummy` error message.... i hope it's not us. any ideas in thread

```2022/12/10 00:10:51 [DEBUG] pact setup 2022/12/10 00:10:51 [DEBUG] initialising rust mock server interface 2022/12/10 00:10:51 [DEBUG] log_to_stdout res 0 2022/12/10 00:10:51 [DEBUG] pact add V3 interaction 2022-12-10T00:10:51.555975Z ERROR ThreadId(01) pact_ffi::mock_server::bodies: Failed to parse matching rule from JSON - dummy is not a valid matching rule type 2022/12/10 00:10:51 [DEBUG] pact verify 2022/12/10 00:10:51 [DEBUG] mock server starting on address: 127.0.0.1:0 2022/12/10 00:10:51 [DEBUG] mock server running on port: 38365```

```libpact_ffi: libname: libpact_ffi version: 0.3.15 hash: e4babe9bd82761f01f595a9fd31a0eb8```

fwiw, it's just an error showing red and doesnt seem to fail the build.... we noticed this along with another test failure which we just cleaned up

also in libpact_ffi-v0.3.14 according to our builds

That is strange. My guess is it's in Pact Go. I'll check tonight

OK because of reasons, all things that can accept a Matcher need to be JSON serialisable. This meant that plain string values got escaped with a `"` so I must have used a dummy matcher a few years back. It seems like it doesn?t cause a functional issues, but I?ve put in a minor fix that essentially detects a string value there and prevents the additional quotes.

It?s in the latest `2.x.x` that has not been released yet (i.e. tagged)

Would you mind seeing if that makes the issue go away?

yep - i'll take a look this morning.

@matt.fellows - looks good now! I was able to replicate the issue using the prior pact-go 2.x.x version only after updating my local `libpact_ffi` to `0.3.15`. And ultimately verified your fix on the head of branch 2.x.x. Thanks for fixing!

correction, it was `v2.0.0-beta.17.0.20221212070231-76032bbaf2b6` i verified.

Awesome, thank you! I?ll get a new release out in the next couple of days

Am I correct? ? Pact Ruby Standalone support Pact Specification 2.x ? Pact Rust FFI support Pact Specification 2.x, 3.x, 4.x

AFAIK ? Pact Ruby Standalone support Pact Specification 1, 1.1, 2.x ? Pact Rust FFI support Pact Specification 1, 1.1, 2.x, 3.x, 4.x ? or at least you can specify them all. https://github.com/pact-foundation/pact-reference/blob/dbe569502561c7d300e2bc428e3553617d4a838b/rust/pact_ffi/src/models/pact_specification.rs#L24-L36 what that actually means to full end to end support of mix and matching. I would assume that theoretically means anyone on a ruby core backed language cannot verify 3.x/4.x pacts and may have limited support for message pacts

some languages have the ability to generate 3.x message pacts, like pact-python which still uses the ruby core https://github.com/pact-foundation/pact-python/blob/d87d54bce2ed2f74b0a2bb46314b18541bdb598a/pact/message_pact.py#L42 https://github.com/pact-foundation/pact-message-ruby There is an open ticket on https://github.com/pact-foundation/pact-message-ruby/issues/6 for support in that gem for v3 message support. It might be better to use the ffi via ruby https://github.com/YOU54F/pact-ruby-ffi/blob/main/lib/pact_ruby_ffi.rb

btw thank you for the awesome PHP examples in pact-reference They inspired me ? https://github.com/pact-foundation/pact-reference/blob/master/php/src/consumer-2.php :chef-kiss: ? https://github.com/YOU54F/pact-python-ffi/blob/main/pact_message_v3.py ? https://github.com/YOU54F/pact-ruby-ffi/blob/main/spec/pactffi_create_message_pact_spec.rb Plugin examples ? https://github.com/pact-foundation/pact-reference/blob/php_plugins/php/src/consumer-plugin.php ? https://github.com/YOU54F/pact-python-ffi/blob/main/pact_plugin_grpc_v4.py ? https://github.com/YOU54F/pact-ruby-ffi/blob/main/examples/area_calculator/spec/pactffi_create_plugin_pact_spec.rb ? https://github.com/YOU54F/pact-bun/blob/main/src/grpc.consumer.raw.test.ts ? https://github.com/YOU54F/hello_ffi/blob/main/deno/hello_pact_grpc.ts ? https://github.com/YOU54F/hello_ffi/blob/main/swift/hello_grpc.swift ? https://github.com/YOU54F/hello_ffi/blob/main/perl/hello_grpc.pl ? https://github.com/YOU54F/hello_ffi/blob/main/lua/hello_grpc.lua Other language examples based on based on this Ruby example (which is where I started originally in FFI land - https://github.com/pact-foundation/pact-reference/blob/master/ruby/example_consumer_spec/spec/simple_consumer_spec.rb) ? https://github.com/YOU54F/hello_ffi/blob/main/zig/hello_pact_mock_server.zig ? https://github.com/YOU54F/hello_ffi/blob/main/raku/hello_pact_mock_server.raku

its been a fun little advent of code style polyglot puzzle game for me

Hey all! Do we have canonical examples of ffi usage for the lifecycle of ? http v3 pact test ? message v3 pact test ? http v4 pact test ? Message async v4 pact test ? Message sync v4 pact test ? Plug-in v4 pact test Can the FFI deal with creating and verifying v2 pacts as well? If so canonical examples would be great for that. Some examples around certain other lifecycles ? logging ? Error handling ? Pact file writing There is some existing useful examples / docs, I used the PHP ones as my go to to replicate ? canonical examples in c https://github.com/pact-foundation/pact-reference/tree/master/rust/pact_ffi/examples ? Arch https://github.com/pact-foundation/pact-reference/blob/master/rust/pact_ffi/ARCHITECTURE.md ? PHP https://github.com/pact-foundation/pact-reference/tree/php_plugins/php/src ? Python https://github.com/pact-foundation/pact-reference/tree/php_plugins/python ? There are other Lang examples in that repo ( c / js / ruby ) I?ve been on a little journey learning about FFI / C interop over that last couple of months as a bit of a side thing, as I didn?t know enough about the low level workings of Pact! https://github.com/YOU54F/hello_ffi

Also would it be useful to authors to be able to see comparable implementations in each of the languages, either samples of direct usage of the ffi, or usage of the ffi in our existing client libraries ( both official and community ) I?ve thought about pulling these into a docs page with code tabs, so I can easily glance across say pact-js-core / pact-net and the current WIP?s done by community members of pact-PHP and pact-python

> Can the FFI deal with creating and verifying v2 pacts as well? Yes, it should support all the spec versions as it just wraps Pact-Rust

qq - was there a change to the minimum supported version of glibc for libpact_ffi? it seems like the min was `2.28`, but i'm noticing an old build image that use to fail due to an older glibc now passed. so curious and not complaining.

yep, I think we now support back to 2.24. See also https://github.com/pact-foundation/pact-reference/issues/202

:fbwow: i had no idea - thank goodness for this additional support.

Hi https://github.com/pact-foundation/pact-reference/blob/master/rust/pact_ffi/src/mock_server/handles.rs#L1038 Is `{"value": ["2","3"]}` the same with `{"value": ["2","3"], "pact:matcher:type": "values"}` ? In other words: If both `pact:matcher:type` and `pact:generator:type` are missing, and `value` is an array, `pact:matcher:type` will be set to `values` ?

No, I don't think so.

Looking at the code, it will just treat it as a normal array

:+1: thanks for the info

Hi, are there any way to disable this log: ```The pact at BROKER_URL is being verified because the pact content belongs to the consumer version matching the following criterion: * latest version from branch 'main' (1.0.0) Verifying a pact between CONSUMER and PROVIDER A get request to /marriages/{id} Given A marriage with id 754992c7-c9b8-44d0-840d-9173497ba6e3 exists Request Failed - One or more of the setup state change handlers has failed A get request to /users/{id} Given A user with id dcd79453-7346-4423-ae6e-127c60d8dd20 exists Request Failed - One or more of the setup state change handlers has failed Failures: 1) Verifying a pact between CONSUMER and PROVIDER Given A marriage with id 754992c7-c9b8-44d0-840d-9173497ba6e3 exists - A get request to /marriages/{id} - One or more of the setup state change handlers has failed 2) Verifying a pact between CONSUMER and PROVIDER Given A user with id dcd79453-7346-4423-ae6e-127c60d8dd20 exists - A get request to /users/{id} - One or more of the setup state change handlers has failed There were 2 pact failures``` I think this log is not affected by these 3 ways: ? `$this->ffi->pactffi_init('PACT_LOGLEVEL');` I think only for mock server, do nothing for verifier ? `$this->ffi->pactffi_init_with_log_level('off');` only print more log, can't disable ? `$this->ffi->pactffi_logger_init();` & `$this->ffi->pactffi_logger_attach_sink('stdout', $this->ffi->LevelFilter_Off);` & `$this->ffi->pactffi_logger_apply();` doesn't work as well Don't get me wrong, this log is very useful. But after I fix the problem in the log, I think I want the output a bit shorter when running the tests.

I don?t think so, as this is the key output that all users must see. It?s not a ?log? message, as such

Thank Matt

It is not log output, but written to standard out

There is no level associated with it.

Hi, when working with grpc plugin, I saw this behavior, so I want to discuss about it: At first I call `pactffi_verifier_set_provider_info` , it will create a default provider's transport `{transport: "http", port: None, part: "/", scheme: None}` . Then I call `pactffi_verifier_add_provider_transport` , it will create second provider's transport `{transport: "http", port: 8000, part: "/", scheme: "http"}` . Finally I call `pactffi_verifier_execute` , the result is `false` because it call provider on the wrong port (http://localhost, because it use the first transport, the provider is located at http://localhost:8000) Do you think it's an issue? If yes, I can think of some solutions for it: ? Implement `pactffi_verifier_set_provider_info_v2` that didn't create default provider's transport https://github.com/pact-foundation/pact-reference/compare/master...tienvx:pact-reference:solution-1 ? Don't create the default provider's transport at all https://github.com/pact-foundation/pact-reference/compare/master...tienvx:pact-reference:solution-2 ? When calling `pactffi_verifier_set_provider_info` , set `scheme` to something that will be never used e.g. `scheme=invalid => transport=invalid` https://github.com/pact-foundation/pact-reference/compare/master...tienvx:pact-reference:solution-3 ? Instead of appending new transport, try to find the existing transport with the same name and update port + part + scheme (no code, I don't think I know how to do it properly) Some notes: ? This is why I think this issue is valid: I saw this attribute on provider info's protocol, port and path: `#[deprecated(note = "Use transports instead")]` ? The example with 2 transport with the same name `http` may look strange to you. You may ask: so why don't call `pactffi_verifier_add_provider_transport` at all? Just put the port=8000 in the first call to `pactffi_verifier_set_provider_info` . The answer for this is the note above. ? I need to test calling to `pactffi_verifier_add_provider_transport` because when working with the grpc plugin, I think calling `pactffi_verifier_add_provider_transport` is required so that the provider's verifier can work. The default transport `http` doesn't work with grpc

I think the actual fix should be that `pactffi_verifier_add_provider_transport` should update the existing entry if it has no port set, and not add the second one. The problem is that if we always update the entry, you can't have two different providers on different ports.

I need to think through "Don't create the default provider's transport at all". It was added to make the transport entries correspond to the deprecated fields. But maybe it should have a fallback to the deprecated fields, i.e., they are an implicit entry. But this may cause other issues.

Another idea from me is to create new ffi function `pactffi_v`er`ifier_set_provider_tr`ans`ports` with json parameter for example

I think I need help with `verifying service method interaction with a gRPC server` https://github.com/pactflow/pact-protobuf-plugin#service-method-provider I choose to write unit test to verify instead of using `pact_verifier_cli` . This part of the unit test: ```public function testPactVerifyConsumer() { $config = new VerifierConfig(); $config->getProviderInfo() ->setName('protobufProvider') ->setHost('127.0.0.1') ->setScheme('tcp') ->setPort(9001); $providerTransport = new ProviderTransport(); $providerTransport ->setProtocol('grpc') ->setScheme('tcp') ->setPort(9001) ->setPath('/') ; $config->addProviderTransport($providerTransport); if ($logLevel = \getenv('PACT_LOGLEVEL')) { $config->setLogLevel($logLevel); } $verifier = new Verifier($config); $verifier->addDirectory(__DIR__.'/../../../broker/pacts'); $this->assertTrue($verifier->verify()); }``` This is the output: ```Verifying a pact between protobufConsumer and protobufProvider request for calculate shape area (0s loading, 2ms verification) Request Failed - builder error for url (): URL scheme is not allowed Failures: 1) Verifying a pact between protobufConsumer and protobufProvider - request for calculate shape area - builder error for url (): URL scheme is not allowed``` This is part of the log I think it's useful: ```2023-03-23T10:56:35.997068Z INFO ThreadId(01) verify_interaction{interaction="request for calculate shape area"}: pact_verifier: Running provider verification for 'request for calculate shape area' 2023-03-23T10:56:35.997099Z DEBUG ThreadId(01) verify_interaction{interaction="request for calculate shape area"}: pact_verifier: Verifying a synchronous message (request/response) 2023-03-23T10:56:35.997212Z INFO ThreadId(01) verify_interaction{interaction="request for calculate shape area"}: pact_verifier::provider_client: Sending request to provider at 2023-03-23T10:56:35.997230Z DEBUG ThreadId(01) verify_interaction{interaction="request for calculate shape area"}: pact_verifier::provider_client: Provider details = ProviderInfo { name: "protobufProvider", protocol: "tcp", host: "127.0.0.1", port: Some(9001), path: "/", transports: [ProviderTransport { transport: "tcp", port: Some(9001), path: Some("/"), scheme: None }, ProviderTransport { transport: "grpc", port: Some(9001), path: Some("/"), scheme: Some("tcp") }] } 2023-03-23T10:56:35.997244Z INFO ThreadId(01) verify_interaction{interaction="request for calculate shape area"}: pact_verifier::provider_client: Sending request HTTP Request ( method: POST, path: /, query: None, headers: Some({"Content-Type": ["application/json"]}), body: Present(447 bytes, application/json) ) 2023-03-23T10:56:35.997257Z DEBUG ThreadId(01) verify_interaction{interaction="request for calculate shape area"}: pact_verifier::provider_client: body: {"description":"request for calculate shape area","request":{"contents":{"content":"EgoNAABAQBUAAIBA","contentType":"application/protobuf;message=ShapeMessage","contentTypeHint":"BINARY","encoded":"base64"},"matchingRules":{"body":{"$.rectangle.length":{"combine":"AND","matchers":[{"match":"number"}]},"$.rectangle.width":{"combine":"AND","matchers":[{"match":"number"}]}}},"metadata":{"contentType":"application/protobuf;message=ShapeMessage"}}} 2023-03-23T10:56:35.997298Z DEBUG ThreadId(01) verify_interaction{interaction="request for calculate shape area"}: pact_verifier::provider_client: Native request builder: RequestBuilder { method: POST, url: Url { scheme: "tcp", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("127.0.0.1")), port: Some(9001), path: "", query: None, fragment: None }, headers: {"content-type": "application/json"} ``` Do you know how to solve that error `URL scheme is not allowed` ?

After adding some more debug message and compiling `pact_ffi` , I see the real issue: `transport` is missing from pact file: ```{ "consumer": { "name": "protobufConsumer" }, "interactions": [ { ................. "transport": "grpc" } ], "provider": { "name": "protobufProvider" } }``` How can I add this value to pact file?

The transport should be in the pact file https://github.com/pact-foundation/pact-reference/blob/9b1b7965f0b97a8c7d11f2d8bb6bbeaa5a79e482/php/pacts/grpc-consumer-php-area-calculator-provider.json#L70-L71 I also noted some odd behaviour with `pactffi_verifier_set_provider_info` & `pactffi_verifier_add_provider_transport` I jotted some comments and experiments when trying to verify both a plugin pact (grpc) and http pact and trying to set the correct transports for both ```// ? // This would be my preferrred option // Set the provider name (which should be used by anything using the verifier_handle, and filter sourced pacts that don't contain name) // add multiple transports. // note pactffi_verifier_set_provider_name does not exist // update_provider_info might work // https://github.com/pact-foundation/pact-reference/blob/cfb2c03f87b3f67464291dd936d0aac555c42c91/rust/pact_ffi/src/verifier/handle.rs#L89 // but is marked as deprecated. // // also worthy of note, if pactffi_verifier_set_provider_info didn't mix with the information used in pactffi_verifier_add_provider_transport // this probably wouldn't be neccessary. $ffi->pactffi_verifier_set_provider_name($handle, 'http-provider'); // note this function doesn't exist (wishlist) $ffi->pactffi_verifier_add_provider_transport($handle, 'http',8000,'/','http'); $ffi->pactffi_verifier_add_provider_transport($handle, 'protobuf',37757,'/','tcp');```

Looks related to your comments here https://pact-foundation.slack.com/archives/C02BXLDJ7JR/p1679503099374349 will take some time to go through them properly today

How can I forgot these valued comments. Let me check through them. Thanks

I found solution (based on your example): replace `pactffi_pact_handle_write_file` by `pactffi_write_pact_file` . I think because mock server know what transport it's using (by calling `pactffi_create_mock_server_for_transport`), asking it to write pact file will have additional `transport` information. I think this useful information should be mentioned somewhere , at least in the `pact.h` file?

Ahhh fabulous, glad they were helpful to you, it was your PHP examples that helped me in the first place :smile: I think capturing some of these thoughts maybe in https://github.com/pact-foundation/pact-reference/blob/master/rust/pact_ffi/ARCHITECTURE.md or some kind of documentation for consumers of the FFI (being Authors/maintainers of pact client libraries) I love the idea of the reference implementations which really strip away from the client libraries DSLs and show the raw FFI calls for particular scenarioes, which then are easier to translate across to other languages as there is a clear view on what methods/args/ordering is required for said feature

or in the header file, tbh that is where I read most of the comments, however its harder to get too, as you have to get it from the releases pages. It would also be cool if the pact.h was annotated with the ffi version that it is for, I don't think there is a version in it, so you rely on it being supplied with the shared lib (which the pact client libs take care off but more awk when your testing against diff ffi versions directly)

Also, tcp is not a valid scheme `setScheme('tcp')`, it should be grpc.

> tcp is not a valid scheme `setScheme('tcp')`, it should be grpc I assume this note is for providerInfo part only. I removed it once I found solution above.

Add a comment about `pactffi_write_pact_file` into the file https://github.com/pact-foundation/pact-reference/blob/php_plugins/php/src/consumer-plugin.php, then create a PR to merge branch `php_plugins` into `master` is another option, but it's less obvious, and only for people who interest in reading PHP code only

There are 5 official log levels mentioned in https://github.com/pact-foundation/pact-specification#logging-in-a-pact-library: ? Error ? Warn ? Info ? Debug ? Trace To turn off log, there is another log level. But what is exactly its name? ? Stub Server (Rust) called it `none` https://github.com/pact-foundation/pact-stub-server#command-line-interface ? While Pact FFI (c header) called it `off` , as in `LevelFilter_Off`, https://github.com/pact-foundation/pact-reference/releases/download/libpact_ffi-v0.4.1/pact.h

Turning off logging is not really a log level, it is a flag that you do not want any logging. TBH, I don't really see the value of it. Why would you not want to at least see if there is an error?

Sorry I didn't ask about how it work. I just ask about naming because I saw inconsistent in the name. For now I think I can just ignore `none` and `off`

has joined #libpact_ffi-users

has joined #libpact_ffi-users

I'm trying to add v4 support to PactNet and I've got in a real mess when I try to use it for real at work. Not every pact will be upgraded to v4 at once (we can't enforce that), so we'll have a mix of: ? v2 pacts with HTTP interactions ? v3 pacts with HTTP interactions ? v3 pacts with message interactions ? v4 pacts with HTTP and/or message interactions The verifier gets in a serious mess when this happens. It starts sending the HTTP requests to the `/pact-messages` endpoint as if they're async requests, which then fails because obviously those are in a completely different format to what's expected. What am I supposed to do in that situation?

As in, you have a Pact file that has different versioned interactions in them? Or different consumers are on different versions of the pact spec?

The latter, yeah - some consumers have like v2 HTTP pacts and some have v4 pacts, but the verifier picks up the v2 pact and treats all the HTTP interactions like they're messaging interactions and hammers the provider with a bunch of invalid requests