Some good news - just migrated one of our many APIs to use PactNet v4 and the consumer tests are all passing 👍 I've compiled it with: • the PR above which fixes the mintype matcher • a custom Rust core build which uses the

native-tls

feature of reqwest instead of the

rustls

version I'm gonna try out the provider tests now and see what happens

Worth noting that I'm not 100% what those flags actually do though. I assume they only consider provider pacts with a matching branch/tag?

I'm just trying to think of what's outstanding for

4.0.0-beta.1

and I can't think of much. I'm not sure if any of them are particularly blockers, but still to do off the top of my head: • GitHub Action for publishing to NuGet when you create a tag (easy, 10mins work) • A new FFI version with

reqwest

updated to fix the panic related to invalid certificates ◦ I'm not sure this is a blocker for a beta, but it totally breaks on my machine and I imagine others will have the same problem. I think it's a blocker for a proper release though because it literally just crashes and there's no real way to work around it. • I'm not quite sure where messaging pacts are up to, but if they do work then we definitely don't have any documentation for them. I'm not entirely sure they're finished at the moment though ◦ Again, I don't think this is a blocker as there would be no breaking API changes for request/response interactions So I think what I'm saying is the only thing needed for a beta is writing the GitHub Action.... 😮 I'll do that now

#347 feat: add arm64 osx libs Pull request closed by adamrodger pact-foundation/pact-net

It is done 😄 Published beta.1 and made sure it's listed on nuget.org. I'll be looking for early feedback - not necessarily expecting this to be the final finished version and so breaking changes are still possible up until a full release, but please try it out and let me know what you find. It's taken an awful lot of effort to get to this point and there's still plenty more to go I'm sure, but that's a milestone that feels good 🎉

Hello I'm trying to implement the A->B->C scenario using the suggestion here: https://gist.github.com/bethesque/43eef1bf47afea4445c8b8bdebf28df0#file-index-md I would like to implement the solution 1 involving "shared artifacts or fixtures" to tie upstream and downstream pacts together. But I'm not sure how this "tying" of pacts can be achieved? Is there any code example or workshop where this method is used? Any ideas, hints? Thanks

Looking at this comment on the github issue for new co-maintainer

• Introducing message support into the framework

Does "message" support here refer to messaging, e.g. queues, etc? And does "framework" refer to just the .NET implementation or pact as a whole?

Hello guys. I'm exploring Release - 4.0.0-beta.1. Couldn't find a way to define provider states on consumer side. How can I do this?

In regard to what my colleague (@David Hvilava)is talking in the previous version we have the Given clause. When doing the consumer contract test now the pact doesn't have it anymore

Hey good people, i have a consumer contract that that has a regex matcher in expectations (for a pre-signed url). What the consumer is expecting is a pre-signed s3 url. Before it was in a format like:

<http://s3:9000/tenantdata/tenants/00000000-0000-0000-0000-000000000001/applications/dda8be6e-e132-4892-a441-63b3a30bfaff/s>

but recent architectural changes have made us to change the url format to a new one

<http://s3:9000/plat-t00000000000000000000000000000001/applications/dda8be6e-e132-4892-a441-63b3a30bfaff/sourcecode-d281f084-1666-3fa4-06ce-1a1214d3692c?X-Amz-Expires=600&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=accessKey1/20220216/us-east-1/s3/aws4_request&X-Amz-Date=20220216T123217Z&X-Amz-SignedHeaders=host&X-Amz-Signature=fb7b255661baa9ebeb991a8a2f16a7f8e93f9a978eeca129a534c89255bca838>

Now the consumer side already changed the matcher in code and published the new contract in CI to pact-broker but is still giving up the old matcher and thus our provider test fails. We are already asking for the latest version by the way. Does the mechanism that pact-broker uses to check if it's a new version of the contract take in account the matchers or it just takes in account changes in keys

Helllo guys! One question. Was a PactPublisher deprecated in version 4?

Hello all, we have a service that we're contract testing and in it we have an end-point that returns an indeterminate amount of values in a array. Part of the consumer contrat is as follows

"response": {
        "status": 200,
        "headers": {
          "Content-Type": "application/json; charset=utf-8"
        },
        "body": {
          "revisionBaseline": 1,
          "baseProperties": [
            {
              "dataType": "",
              "defaultValue": "",
              "value": "",
              "valueOrigin": "",
              "key": ""
            }
          ]
        },
        "matchingRules": {
          "$.body.baseProperties[0].dataType": {
            "match": "regex",
            "regex": ".*"
          },
          "$.body.baseProperties[0].defaultValue": {
            "match": "regex",
            "regex": ".*"
          },
          "$.body.baseProperties[0].value": {
            "match": "regex",
            "regex": ".*"
          },
          "$.body.baseProperties[0].valueOrigin": {
            "match": "regex",
            "regex": ".*"
          },
          "$.body.baseProperties[0].key": {
            "match": "regex",
            "regex": ".*"
          }
        }
      }
    }
  ],

The problem is that it's just not 1 element but a array of them (at least 10+ of them) How can we setup an expectation on consumer side that would check this (that it receives an array of objects like this). Is it possible, and if it is, how can we set it up?

Hi crew. Great work on 4.0.0. I’m having some trouble getting verification results to output to console. I know that output is occurring because pointing the verifier to a bad pact file location spits out a bunch of output. Has anyone reported this? I’ve tried xunit and nunit. Same results. Makes it very hard to know where verification fails.

Hi all. I'm having some issues getting the Messaging example to work. When I try to implement it, the IMessagePactBuilderV3.WithJsonContent() is not returning an IConfiguredMessageVerifier, but an IMessagePactBuilderV3. So the .Verify() method cannot be resolved in the ReceiveSomeStockEvents() test, because it thinks it's the wrong type. I created a minimal repo that shows the issue here: https://github.com/rishispeets/pact-net-messaging-example-test/blob/master/TestProject1/StockEventProcessorTests.cs. I get the same behaviour in a non-trivial project. It's the exact same copied code from the PactNet repo, but I must be doing something wrong, because it works when I clone the PactNet repo and run that. Does anybody know what the issue might be? (I'm pretty new to dotnet btw)

It's not, that's why there's an open issue on PactJS about it also 😄 https://github.com/pact-foundation/pact-js/issues/304

I publish a new version just when it seems sensible to do so

Hi I have a Pact.NET consumer unit test using .NET 6.0 which works normally on two different local Windows developer machines but it fails if the same code is built and executed in the linux docker image mcr.microsoft.com/dotnet/sdk:6.0-alpine. I get the following error: System.TypeInitializationException : The type initializer for 'PactNet.Native.Interop.NativeInterop' threw an exception. ---- System.DllNotFoundException : Unable to load shared library 'pact_ffi' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: Error loading shared library libpact_ffi: No such file or directory Any ideas?

Hello o/ we have pact net running in necoreapp2.1, (tested with PactNet 3.0.2 and 2.6.1). The main problem that we are facing is that pacts show up in pact-flow as unverified, (with the contents of the pact indicating that verification on the individual contracts did in fact ran), while pactnet runner (xunit) pact verifier DOES NOT assert the test and does not mark a unit test as failed when in fact pacts did not verify successfully. Can someone please advise me on what could be the cause of this behavior. Thanks

Worth noting that .Net Core 2.1 has been deprecated and unsupported since August 2021

Interested to know if anyone here is using pact to test azure function apps? I've created an example, maybe an opportunity to compare notes?

Hi, I was successful to implement a consumer unit test involving a method sending a HttpMethod.Delete request and a parameter. The request works if the request path is without the name of the parameter as follows:

.WithRequest(HttpMethod.Delete, "/api/products/13")

But if I change the path to include the parameter name as follows, the request fails:

.WithRequest(HttpMethod.Delete, "/api/products?id=13")

In this case the HttpClient.DelectAsnyc() method returns the following error:

{StatusCode: 500, ReasonPhrase: 'Internal Server Error', Version: 1.1, Content: System.Net.Http.HttpConnectionResponseContent, Headers:
{
 Access-Control-Allow-Origin: *
 x-pact: Unexpected-Request
 Date: Wed, 16 Mar 2022 11:23:47 GMT
 Content-Type: application/json; charset=utf-8
 Content-Length: 329
}}

Does Pact.NET mock provider not support named parameters in the request query?

I’m not a .NET person, but do you need to explictly serialise the JSON there? I think you can pass the object directly into

WithJsonBody

Hi, I have following code

options.PublishResults(_providerVersion, publishOptions =>
                        {
                            publishOptions.BuildUri(new Uri("<http://example.com>"));
                            publishOptions.ProviderBranch(_providerBranch);
                        });

Unless build uri is set, verify throws NullReferenceException. Version is

4.0.0-beta.3

. Should I create an issue on github?

Hi there, anyone using the new pact-net nugget (pact-net 4.x.x) got a timeout when doing provider state request?

[INFO][pact_verifier] Running provider state change handler 'There exists 1 application revision 1' for 'A GET request to fetch application detail'
[DEBUG][pact_verifier::provider_client] Sending HTTP Request ( method: POST, path: /, query: None, headers: Some({"Content-Type": ["application/json"]}), body: Present(129 bytes, application/json) ) to state change handler
[DEBUG][reqwest::connect] starting new connection: <http://localhost:9001/>
[DEBUG][hyper::client::connect::http] connecting to [::1]:9001
[DEBUG][hyper::client::connect::http] connected to [::1]:9001
[DEBUG][pact_verifier::provider_client] State change request failed with error error sending request for url (<http://localhost:9001/provider-states>): operation timed out
[DEBUG][pact_verifier] State Change: "ProviderState { name: "There exists 1 application revision 1", params: {} }" -> Err(Provider state failed: (interaction_id: a64ddfb75ada4126584b9646620cc01271e1d3c3) Invalid response: error sending request for url (<http://localhost:9001/provider-states>): operation timed out)
[ERROR][pact_verifier] Provider state change for 'There exists 1 application revision 1' has failed - MismatchResult::Error("Invalid response: error sending request for url (<http://localhost:9001/provider-states>): operation timed out", Some("a64ddfb75ada4126584b9646620cc01271e1d3c3"))
[INFO][pact_verifier] Running provider state change handler 'There exists 1 application revision 1 with 2 producers' for 'A GET request to fetch the producers'
[DEBUG][pact_verifier::provider_client] Sending HTTP Request ( method: POST, path: /, query: None, headers: Some({"Content-Type": ["application/json"]}), body: Present(225 bytes, application/json) ) to state change handler
[DEBUG][reqwest::connect] starting new connection: <http://localhost:9001/>
[DEBUG][hyper::client::connect::http] connecting to [::1]:9001
[DEBUG][hyper::client::connect::http] connected to [::1]:9001
[DEBUG][reqwest::async_impl::client] response '200 OK' for <http://localhost:9001/provider-states>

It's just 1 interaction. Other that use the same provider state passes. Before the upgrade, it worked fine.

@here why does the new pact-net nugget is calling all provider state in parallel before even 1 test starts to run? This give sproblem when you have state that have completely competitive states

the request response i got:

{
  "baseProperties": [
    {
      "dataType": "Text",
      "defaultValue": "",
      "value": "",
      "valueOrigin": "EnvironmentLevelOverride",
      "isSecret": false,
      "secretKey": null,
      "key": "OutSystems:Application:Key"
    },
    {
      "dataType": "Text",
      "defaultValue": "",
      "value": "My Test",
      "valueOrigin": "EnvironmentLevelOverride",
      "isSecret": false,
      "secretKey": null,
      "key": "OutSystems:Application:Name"
    },
    {
      "dataType": "Text",
      "defaultValue": "",
      "value": "",
      "valueOrigin": "EnvironmentLevelOverride",
      "isSecret": false,
      "secretKey": null,
      "key": "OutSystems:Application:Description"
    }
  ]
}

Hello everyone, my team is currently working on PoC to evaluate the usage of the PactFlow in our APIs. We have a lot of questions that the documentation itself its not very clear how to implement. How can we find some support for this tool?

Wondering if there are before and after pact verify options like in pact-js?

quick questions: does pact-net 4.x supports pact specification 4.0? or just until 3.0?

Hi, I am trying to upgrade pactnet from 3.0.x to 4.0.x. I want to specify the port but it seems that PactConfig doesn't have the option anymore. However, the documentation does say that it is possible. How do I specify the port ?