#548 Extract PactNet.Interop package and add Grpc Support Pull request opened by max-lancaster I have read through issue #492 thoroughly and examined the source code and feel that I have a decent understanding of what's involved in adding plugin support, specifically for Grpc. I was able to take @Yousaf Nabi (pactflow.io)'s example and create this PR to get some sample Grpc tests working. I have extracted a

PactNet.Interop

package as @adamrodger suggested in Issue #492 . This was not a breaking change since all the classes in this namespace were internal,

PactNet

now references this new package and none of the pre-existing interface methods have changed. Extracting this package made it possible to create bare-bones Grpc plugin tests and is effectively a very "raw" way of using any plugin. Perhaps a next step would be to wrap the bare-bones methods in a more fluent "raw" interface in a plugin package similar to implementations in other languages as @Matt (pactflow.io / pact-js / pact-go) suggested. Based on above "raw" tests I was able to refactor and extract shared functionality to create a new

PactNet.Extensions.Grpc

library that provides a fluent interface similar to the interfaces for http / rest and asynchronous messaging interactions. An alternative approach here would be to just add

<InternalsVisibleTo Include="PactNet.Extensions.Grpc" />

to the PactNet.csproj file but this allows integration of other plugins in repos outside this one so it depends on whether you want to explicitly allow that or not. pact-foundation/pact-net

Hi all, I’m trying to work with message pacts in PactNet where the consumer expects the payload to be

text/plain

instead of JSON. What I’ve noticed: • On the consumer side, the DSL only exposes helpers like

WithJsonContent(...)

which always serialize the messages to JSON. I don’t see a way to say "the body is raw text and the contentType is `text/plain`". • On the provider side, when using

.WithMessages(...).WithContent(...)

, any

string

gets serialized as JSON and the content type ends up

application/json

. I don’t see an overload that doesn't take the JsonSerializationOptions. So essentially: I don’t see a way in PactNet to produce or verify a message pact where the body is plain text and the content type is

text/plain

. 👉 My questions: • Is this a known limitation in PactNet? • Or is there some sample code / workaround that shows how to handle non-JSON content types (like

text/plain

) in message pacts on .NET? We’re using PactNet 5.0.1 (

PactNet

+

PactNet.Abstractions

). Thanks in advance!

#549 PactNet.sln line endings are in illegal git state Issue created by max-lancaster When interactively rebasing and editing a commit or checking out a new branch the PactNet.sln file line endings get modified which makes a lot of git functionality unusable. Issue is described in this stack overflow issue. I have reproduced this on both Mac Os and Windows so it is not an OS specific defect. To reproduce if you just clone the repo and do a

git status

you will see that PactNet.sln all line-endings have immediately changed. Potential solution is described in the accepted answer of the above referenced SO post. Appears that the root cause may be that line endings were not renormalized (

git add --renormalize .

) when the .gitattributes file was added. pact-foundation/pact-net

@Paul has left the channel

@Elson Ho has left the channel

1 new commit pushed to

<https://github.com/pact-foundation/pact-net/tree/master|master>

by adamrodger

<https://github.com/pact-foundation/pact-net/commit/8b8841d4074c17363fa22e62a105711e88eb24a4|8b8841d4>

- Fix content creation syntax in messaging pacts pact-foundation/pact-net

1 new commit pushed to

<https://github.com/pact-foundation/pact-net/tree/master|master>

by adamrodger

<https://github.com/pact-foundation/pact-net/commit/3f59bf7cb00124635b6d421a033b2a4a72c4c3c9|3f59bf7c>

- fix(#549): EditorConfig settings for sln files pact-foundation/pact-net

#550 RFC: Support for synchronous messaging Issue created by evoclint Do you intend to implement synchronous messaging? I can see in the roadmap it isn't yet supported for PactNet, if you intend to support it do you have a rough idea when this will be? pact-foundation/pact-net

#551 Add Synchronous Plugin Interaction Support Pull request opened by max-lancaster @adamrodger I took your commit in the dev/plugins branch that you referenced in Issue #492 and made a "raw" plugin implementation that should work with the

PactNet.Extensions.Grpc

package I created in PR #548. There may still be some design issues to consider. One thing to note is that Plugins can have both synchronous and asynchronous interactions so I made my builder specific to the synchronous use case so we can add an asynchronous version at some point. pact-foundation/pact-net

@Kieran McCarthy has left the channel

#552 Request Failed : builder error for url (message://localhost:49152/pact-messages) Issue created by ibrar434 I have updated the Pactnet From 4.0.5 to 5.0.1 but when i run same messaging test that continuously returns the error I don't understand why this happening even i have updated the code with required changes but this issue comes again and again here is my consumer side code [Image](https://private-user-images.githubusercontent.com/212374163/500884627-2bea34d1-68ad-4bc8-a0d9-e222d76147ed.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjA0NTE3MzksIm5iZiI6MTc2MDQ1MTQzOSwicGF0aCI6Ii8yMTIzNzQxNjMvNTAwODg0NjI3LTJiZWEzNGQxLTY4YWQtNGJjOC1hMGQ5LWUyMjJkNzYxNDdlZC5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUxMDE0JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MTAxNFQxNDE3MTlaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0xN2E5NDRiN2EzODhkMzk3ZTZlODY5ZGQyOGJiMmViMWNiOTQ3YTNjN2ViNjJkN2JjYWY1YWIxODlhNGFhZmQzJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.GTCWC7Zw-pOd3mJ7Ux2F9OUrknriboU7bSvaGZgAmNg) here is my proivder side code [Image](https://private-user-images.githubusercontent.com/212374163/500884732-01b66efc-e68a-41c8-813d-bc9acbde74fe.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjA0NTE3MzksIm5iZiI6MTc2MDQ1MTQzOSwicGF0aCI6Ii8yMTIzNzQxNjMvNTAwODg0NzMyLTAxYjY2ZWZjLWU2OGEtNDFjOC04MTNkLWJjOWFjYmRlNzRmZS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUxMDE0JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MTAxNFQxNDE3MTlaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT04OTA1YzQ5OWM5MTc0NzA1NWZjM2FjZjg1ZGM2MGM0MzI0MGY3ODM2MDhhNjU0NjI4MTQyNWUzOWYyOWU4NDgzJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.kfQ4gflSWDATNG_9P-SItjmFP1ninjlTM7PxJ4NBcbg) and this is the scenerio [Image](https://private-user-images.githubusercontent.com/212374163/500884785-65907d7d-95ee-447f-a358-5812728776e7.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjA0NTE3MzksIm5iZiI6MTc2MDQ1MTQzOSwicGF0aCI6Ii8yMTIzNzQxNjMvNTAwODg0Nzg1LTY1OTA3ZDdkLTk1ZWUtNDQ3Zi1hMzU4LTU4MTI3Mjg3NzZlNy5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUxMDE0JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MTAxNFQxNDE3MTlaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1jYjY2ZWE1NmVlYjdmNDc1MjRhZDJkZjUyZjM4MDVlODVlMmZhODhmNDljZDViYjI4ZTIyMTBmYjYwMGJmNmY1JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.9cw_QTdbwd0kOgMUC-4mJGHTRIlH60gfcsZUsShIvS8) if any idea please help Request Failed - builder error for url (message://localhost:49152/pact-messages) Image pact-foundation/pact-net

#553 Verifying a pact between Web-PermissionsModule and Customers-API Given user does not exist - request to create user Issue created by ibrar434 @akamud edit: don’t tag maintainers in issues! I updated my pactnet From 4.5.0 to 5.0.1 but all the test which work pefectly fine in previous version which is front end related but now is making issue these are also api test where grpc calls inculdes Frontend side code for generating files [Image](https://private-user-images.githubusercontent.com/212374163/501293609-b7fbad70-d4b2-4d14-8db9-04894a6e6e4d.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjA1MjIxODgsIm5iZiI6MTc2MDUyMTg4OCwicGF0aCI6Ii8yMTIzNzQxNjMvNTAxMjkzNjA5LWI3ZmJhZDcwLWQ0YjItNGQxNC04ZGI5LTA0ODk0YTZlNmU0ZC5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUxMDE1JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MTAxNVQwOTUxMjhaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0yNjg1ZTIyNTkyNTBiNGVkMjUyNzFiODMzZjAwYmQ1MTQ1MWI1ZWZkZTg0ZDAxYWE2NWQ4OTQ5MDc4NTVkZGU5JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.ij23IC1oZAhvIu0e_Lz5azjucgJFSHexqLpUso5YGJg) i just change in ApiProivdertest [Image](https://private-user-images.githubusercontent.com/212374163/501290049-b98d1fc1-78fc-434c-952e-bbf1a5bbc64d.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjA1MjIxODgsIm5iZiI6MTc2MDUyMTg4OCwicGF0aCI6Ii8yMTIzNzQxNjMvNTAxMjkwMDQ5LWI5OGQxZmMxLTc4ZmMtNDM0Yy05NTJlLWJiZjFhNWJiYzY0ZC5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUxMDE1JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MTAxNVQwOTUxMjhaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT04OTMxNjFkNDg5NzliYzJkODU1ZDcwZmE3OWIxODI5YTdhOTFiYWVhYTg1NTVhMTE0NjA5YjZjMmNjMTlmYjA5JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.lOEeXmra1YnXMWQXpV5r-A9cxKndoU4nkotqVCiDXlo) Exception is this [Image](https://private-user-images.githubusercontent.com/212374163/501293412-4a07a063-9b69-4904-a13c-89fed8b84acc.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjA1MjIxODgsIm5iZiI6MTc2MDUyMTg4OCwicGF0aCI6Ii8yMTIzNzQxNjMvNTAxMjkzNDEyLTRhMDdhMDYzLTliNjktNDkwNC1hMTNjLTg5ZmVkOGI4NGFjYy5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUxMDE1JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MTAxNVQwOTUxMjhaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0xM2RlYzJmNWQ3MjM5MzI1YTZjM2EzMDAxZDBjNTg1M2RiNzQ3NTAzYWFkN2NkMWEyODc3ZmIzNTY1YWY4NGUzJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.PMdFcE7Oe2T0pnebVvPq8RWPYCoGjGenQM_s1R56xiM) Same Code works in previous but now after updating file not work and gives this exception if anyone have idea please let me know and help pact-foundation/pact-net

#506 Fix/numeric provider state param Pull request opened by YOU54F on <!date^1718020963^{date_short}|2024-06-10T12:02:43Z> fixes #449 • Added examples of generating provider states with number or string values • Serialise value into json, prior to sending over the wire • As per recommendation in pact-foundation/pact-reference#263 (comment) • As per pact-js https://github.com/pact-foundation/pact-js/blob/54087fa06e485f1c7041a0a6f7f14e1cc177e09f/src/v3/pact.ts#L100-L102 relates to • pact-foundation/pact-reference#298 • pact-foundation/pact-reference#263 pact-foundation/pact-net

#502 feat: linux musl detection Pull request opened by YOU54F ## Rationale pact-reference has introduced musl and arm64 based ffi libraries for linux • pact-foundation/pact-reference#416 Tracking Issue • pact-foundation/roadmap#30 ## Issues Resolved fixes #498 fixes #496 fixes #500 fixes #374 fixes #387 ## Backwards Compatibility Linux glibc based hosts take precedence, so if any error occurs during musl detection. I do not anticipate breaking changes for users ## Implementation notes ### .NET notes • Docs • Uses MSBuild Exec task • MSBuild Blog Posts • Cross-Platform Build Events in .NET Core using MSBuild • MSBuild 101: Using the exit code from a command • Stack OverFlow • Set PropertyGroup property to Exec output • .NET runtime musl detection code • https://github.com/dotnet/runtime/blob/a50ba0669353893ca8ade8568b0a7d210b5a425f/src/mono/llvm/llvm-init.proj\#L7 • https://github.com/dotnet/runtime/blob/a50ba0669353893ca8ade8568b0a7d210b5a425f/src/libraries/Common/tests/TestUtilities/System/PlatformDetection.Unix.cs\#L78t ### Conditions for execution musl detection will run if • if linux • if /lib/ld-musl-(x86_64|aarch64).so.1 exists • if ldd bin/sh | grep musl is true (musl lib is loaded, rather than glibc) will continue on error, reverting back to glibc based libaries. ### Supported musl targets should work for multiple musl based distroes if • /lib/ld-musl-(x86_64|aarch64).so.1 exists • ldd is available (available by default in alpine images) Tested on Alpine ARM64 / AMD64. ## Caveats • .NET does not run under QEMU affecting the ability to test multi-arch from a single system • .NET restore can take a long time when running under containers. • Workaround: Set

DOTNET_NUGET_SIGNATURE_VERIFICATION

to

false

## Compatibility ### Operating System Due to using a shared native library instead of C# for the main Pact logic only certain OSs are supported: | OS | Arch | Support | | ------------ | ----------- | ---------------- | | Windows | x86 | ❌ No | | Windows | x64 | ✔️ Yes | | Linux (libc) | x86 | ❌ No | | Linux (libc) | x64 | ✔️ Yes | | Linux (musl) | x64 | ✔️ Yes (Tier 2)* | | Linux (libc) | ARM | ✔️ Yes (Tier 3)* | | Linux (musl) | ARM | ✔️ Yes (Tier 3)* | | OSX | x64 | ✔️ Yes | | OSX | ARM (M1/M2) | ✔️ Yes | #### Support • Tier 1 • Established • Full CI/CD support. • Users should not encounter issues • Full reproducible examples running in CI, should be provided by users raising issues • If using musl targets, users should attempt the same test on a libc target (such as debian) • Tier 2 • Recently introduced • Full CI/CD support. • Users may encounter issues • Full reproducible examples running in CI, should be provided by users raising issues • If using musl targets, users should attempt the same test on a libc target (such as debian) • Tier 3 • Recently introduced, No/limited CI/CD support. • Users may encounter issues • Full reproducible examples which can be run by maintainers locally, should be provided by users raising issues pact-foundation/pact-net

#447 Feat multipart file upload support Pull request opened by Inksprout This PR aims to add partial support for Multipart/form-data requests to be added to the Pact File. It introduces a WithMultipartSingleFileUpload() method that allows the user to to specify a request of multipart/form-data in which a single part is uploaded, which is a file. This functionality is a common use case and uses the underlying Rust FFI method designed for this express purpose. Note this update does not enable Pact-Net to fully support all types of multipart/form-data requests as it does not support requests with multiple parts included. see issue: #410 TODO • Add documentation for the new method pact-foundation/pact-net

#554 chore: fix json schema url Pull request opened by JP-Ellis Schema Store seem to have changed the URL; and while the previous 'json' subdomain should redirect, it seems flakey and results in failures in CI. pact-foundation/pact-net

1 new commit pushed to

<https://github.com/pact-foundation/pact-net/tree/master|master>

by JP-Ellis

<https://github.com/pact-foundation/pact-net/commit/6c88659ee367f3fab7a269e876166d885cdc79d3|6c88659e>

- chore: fix json schema url pact-foundation/pact-net

#555 Suspicious matching async message payload int (35) -&gt; int (30) from the sample code Issue created by kieronwraywork Previous issues Have you searched the issue tracker to ensure this hasn't been discussed before? None found Version information: • OS: Windows x64 • PactNet Version: [MASTER] from this repo • .Net Version: 8.0 • Pact Broker Version (if applicable): NA Describe the bug There is an asynchronous event from the SAMPLES project in this repo, the body contents are matched even though the numbers are different in the content Steps To Reproduce Use this repo pact-net, samples project, change line 137 in the json (this is the contents\content payload for the Asynchronous/Messages type, change the "id" from 1 to any other number. Change the

providertests

code to generate OrderCreatedEvent with any number other than 1 Expected behavior Pact Verify test should fail with body content mismatch Log Output

ated"}: pact_verifier::messages: actual message = AsynchronousMessage { id: None, key: None, description: "Asynchronous/Message Interaction", provider_states: [], contents: MessageContents { contents: Present(b"{\"id\":30}", Some(ContentType { main_type: "application", sub_type: "json", attributes: {}, suffix: None }), None), metadata: {"contentType": String("application/json")}, matching_rules: MatchingRules { rules: {} }, generators: Generators { categories: {} } }, comments: {}, pending: false, plugin_config: {}, interaction_markup: InteractionMarkup { markup: "", markup_type: "" }, transport: None }

2025-12-28T21:57:19.815008Z DEBUG ThreadId(01) verify_interaction{interaction="an event indicating that an order has been created"}: pact_matching: comparing to expected message: AsynchronousMessage { id: None, key: None, description: "an event indicating that an order has been created", provider_states: [], contents: MessageContents { contents: Present(b"{\"id\":35}", Some(ContentType { main_type: "application", sub_type: "json", attributes: {}, suffix: None }), None), metadata: {}, matching_rules: MatchingRules { rules: {BODY: MatchingRuleCategory { name: BODY, rules: {DocPath { path_tokens: [Root, Field("id")], expr: "$.id" }: RuleList { rules: [Integer], rule_logic: And, cascaded: false }} }} }, generators: Generators { categories: {} } }, comments: {}, pending: false, plugin_config: {}, interaction_markup: InteractionMarkup { markup: "", markup_type: "" }, transport: None }

2025-12-28T21:57:19.815059Z DEBUG ThreadId(01) verify_interaction{interaction="an event indicating that an order has been created"}: pact_matching: expected content type = 'application/json', actual content type = 'application/json'

2025-12-28T21:57:19.815069Z DEBUG ThreadId(01) verify_interaction{interaction="an event indicating that an order has been created"}: pact_plugin_driver::catalogue_manager: Looking for a content matcher for application/json

2025-12-28T21:57:19.815900Z DEBUG ThreadId(01) verify_interaction{interaction="an event indicating that an order has been created"}: pact_matching: No content matcher defined for content type 'application/json', using core matcher implementation

2025-12-28T21:57:19.815909Z DEBUG ThreadId(01) verify_interaction{interaction="an event indicating that an order has been created"}: pact_matching: Using body matcher for content type 'application/json'

2025-12-28T21:57:19.815917Z DEBUG ThreadId(01) verify_interaction{interaction="an event indicating that an order has been created"}: pact_matching::json: compare: Comparing path $

2025-12-28T21:57:19.815919Z DEBUG ThreadId(01) verify_interaction{interaction="an event indicating that an order has been created"}: pact_matching::json: compare_maps: Comparing maps at $: {"id": Number(35)} -> {"id": Number(30)}

2025-12-28T21:57:19.815944Z DEBUG ThreadId(01) verify_interaction{interaction="an event indicating that an order has been created"}: pact_matching::json: compare: Comparing path $.id

2025-12-28T21:57:19.815949Z DEBUG ThreadId(01) verify_interaction{interaction="an event indicating that an order has been created"}: pact_matching::json: compare_values: Calling match_values for path $.id

2025-12-28T21:57:19.815953Z DEBUG ThreadId(01) verify_interaction{interaction="an event indicating that an order has been created"}: pact_matching::json: JSON -> JSON: Comparing '35' (Integer) to '30' (Integer) using Integer -> Ok(())

2025-12-28T21:57:19.815957Z DEBUG ThreadId(01) verify_interaction{interaction="an event indicating that an order has been created"}: pact_matching::json: compare_values: Comparing 'Number(35)' to 'Number(30)' at path '$.id' -> Ok(())

2025-12-28T21:57:19.815975Z DEBUG ThreadId(01) verify_interaction{interaction="an event indicating that an order has been created"}: pact_matching: Matching message metadata

2025-12-28T21:57:19.815977Z DEBUG ThreadId(01) verify_interaction{interaction="an event indicating that an order has been created"}: pact_matching: Matching message metadata. Expected '{"contentType": String("application/json")}', Actual '{"contentType": String("application/json")}'

2025-12-28T21:57:19.815982Z DEBUG ThreadId(01) verify_interaction{interaction="an event indicating that an order has been created"}: pact_matching: Comparing metadata values for key 'contentType'

2025-12-28T21:57:19.815989Z DEBUG ThreadId(01) verify_interaction{interaction="an event indicating that an order has been created"}: pact_matching: Comparing message context type '"application/json"' => '"application/json"'

Additional context Suspicious text compare_values: Comparing 'Number(35)' to 'Number(30)' at path '$.id' -> Ok(())

Fulfilment API-Orders API.json

excerpt of contents

{
  "contents": {
    "content": {
      "id": 35
    },
    "contentType": "application/json",
    "encoded": false
  },
  "description": "an event indicating that an order has been created",
  "matchingRules": {
    "body": {
      "$.id": {
        "combine": "AND",
        "matchers": [
          {
            "match": "integer"
          }
        ]
      }
    }
  },
  "pending": false,
  "type": "Asynchronous/Messages"
}

pact-foundation/pact-net

@Paul Williams has left the channel

@Norbert Gulácsi has left the channel

Need help, how the implementation is done at provider side in real time multiservice .net project?

while provider verification, it spins up real app server, or we create a mock server instead of real one, in real time project?

You need to spin up your app server to test it. Message Pact is a little different, but can you please elaborate a bit further on the use case then we can advise more

#550 RFC: Support for synchronous messaging Issue created by evoclint Do you intend to implement synchronous messaging? I can see in the roadmap it isn't yet supported for PactNet, if you intend to support it do you have a rough idea when this will be? pact-foundation/pact-net

#545 PublishResult with / in the provider branch name fails Issue created by scrocquesel Version information: • OS: Linux • PactNet Version: 5.0.1 • .Net Version: 8 • Pact Broker Version (if applicable): 2.107.1 Describe the bug Trying to publish test results with provider branch "/refs/head/test", result in an error

2025-07-10T21:23:11.928119Z ERROR ThreadId(01) pact_verifier::pact_broker: Failed to push branch refs/head/test for provider version test
2025-07-10T21:23:11.928223Z ERROR ThreadId(01) pact_verifier: Publishing of verification results failed with an error: Link/Resource was not found - Request to pact broker path '/pacticipants/myprovider/branches/refs%2Fhead%2Ftest/versions/test' failed: 404 Not Found. URL: '<https://pactbroker.com/>'

Steps To Reproduce

options.PublishResults(brokerConfig.ProviderVersion, publishOptions =>
                    {
                        publishOptions
                            .BuildUri("<http://test>")
                            .ProviderBranch("/refs/head/test");
                    });

Expected behavior The provider verification result should be published to a branch with a slash. This is a supported value with the pact cli to publish consumer contract. Log Output See above Additional context Replacing

/

with

-

make it works. pact-foundation/pact-net

#550 RFC: Support for synchronous messaging Issue created by evoclint Do you intend to implement synchronous messaging? I can see in the roadmap it isn't yet supported for PactNet, if you intend to support it do you have a rough idea when this will be? pact-foundation/pact-net

#557 [Feature Request] Add support for AsyncAPI references in Message Pact (.reference() method) Issue created by mr-roman-vivint Problem When using PactNet to create Message Pact contracts for AsyncAPI Bi-Directional Contract Testing (BDCT) with Pactflow, there's currently no built-in way to link Message Pact interactions to AsyncAPI operations via the

comments.references.AsyncAPI

structure. According to PactFlow's AsyncAPI BDCT documentation, consumer pact files should include operation references like this: { "description": "Message interaction", "comments": { "references": { "AsyncAPI": { "operationId": "receiveUserEvents" } } } } Current State in PactNet PactNet 5.0.1 provides

IMessageBuilderV4.WithMetadata()

but does not expose a

.reference()

method to add AsyncAPI operation references. Workaround (Verified Working) I manually added the

comments.references.AsyncAPI

structure to the generated pact file: { "interactions": [ { "description": "Some interaction", "comments": { "references": { "AsyncAPI": { "operationId": "someOperation" } } }, "metadata": { ... }, "contents": { ... } } ] } After adding this structure manually, PactFlow successfully validated the Message Pact against the AsyncAPI provider specification. This confirms that the feature works end-to-end — PactNet just needs a programmatic way to add these references. Expected Behavior PactNet should support something like this: _pactBuilder .ExpectsToReceive("Some message") .Reference("AsyncAPI", "operationId", "someOperation") // ← Missing .WithJsonContent(new { ... }) .Verify<Message>(...) Or alternatively: _pactBuilder .ExpectsToReceive("Some message") .WithAsyncApiReference("someOperation") // ← Missing .WithJsonContent(new { ... }) .Verify<Message>(...) Use Case This feature is essential for teams using PactFlow's AsyncAPI BDCT approach with .NET Message Pact consumers. Without it, the generated pact files cannot be automatically validated against AsyncAPI provider specifications in Pactflow. Environment • PactNet Version: 5.0.1 • .NET Version: 10.0 • Target: PactFlow AsyncAPI BDCT Thanks in advance! pact-foundation/pact-net

#558 [Bug]: Provider verification with WithMessages fails with "builder error for url (message://...)" due to incorrect URL scheme passed to FFI Issue created by daniloitzep Environment • PactNet version:

5.0.0

and

5.0.1

• Pact Specification: V3 (

messages

) and V4 (

asyncMessage

) • Framework:

.NET 8.0

/

.NET 10

• OS: Cross-platform (macOS, Windows, Linux) --- Describe the bug When performing provider verification for an asynchronous message contract using the new unified

PactVerifier.WithMessages(...)

builder introduced in PactNet 5.0+, the provider verification instantly fails before executing any message scenario or mapper. The underlying Rust verification engine attempts to send HTTP requests to a URL with the scheme

message://

instead of

http://

, which causes the internal Rust HTTP client (

reqwest

) to fail immediately with a URL builder error:

builder error for url (<message://localhost:XXXX/pact-messages>)

. --- Expected behavior PactNet starts a tiny local HTTP server within the test process (`http://localhost:PORT/pact-messages/`) to host the messaging scenarios. When instructing the native Rust engine to verify the interactions, the verification engine should send POST requests via HTTP to that internal server (`http://localhost:PORT/pact-messages/`), receive the serialized message, and compare fields against the contract. --- Actual behavior & Contradictory Logs The verifier logs reveal the exact contradiction in two sequential lines:

Starting messaging provider at   <http://localhost:49152/pact-messages/>     <-- PactNet starts HTTP adapter correctly
Sending request to provider at   <message://localhost:49152/pact-messages/>  <-- Rust FFI engine requests wrong scheme
Request Failed - builder error for url (<message://localhost:49152/pact-messages>)
Because reqwest does not recognize message:// as a valid network transport scheme, the HTTP request never leaves the builder phase, failing with zero field comparisons performed.

Root Cause Analysis
In PactNet 5.0+, when registering the message transport provider via FFI (likely invoking pactffi_verifier_add_provider_transport), two distinct attributes are handled:

protocol: The interaction type (message).
scheme: The network scheme to physically reach the local verification adapter (http).
It appears PactNet correctly registers the protocol as "message", but either leaves the scheme undefined or erroneously passes "message" as the scheme as well. Consequently, the native engine defaults to duplicating the protocol name into the URL scheme, building message://localhost:49152/pact-messages/ instead of http://....

Steps to Reproduce
Create a consumer message test generating a valid message pact (tested with both V3 and V4 specifications).
Set up a provider test using PactVerifier:
csharp
using var verifier = new PactVerifier("MyProvider", config);
verifier
    .WithMessages(scenarios => scenarios.Add("a sample message", () => MyMessageFactory.Create()), jsonOptions)
    .WithFileSource(pactFilePath)
    .Verify();
Run the provider test. Notice that none of the scenario factory methods are invoked, and verification terminates immediately with builder error for url (message://...).
Why this is blocking & tested combinations
We ran systematic testing across multiple matrix combinations to rule out local configuration issues:

PactNet Versions: Fails identically on 5.0.0 and 5.0.1.
Contract Formats: Fails identically on both V3 and V4 specs.
Data/Mapper execution: Confirmed via debugging that scenarios and mappers never get called because the internal POST request fails during URL construction.
Configuration: PactVerifierConfig does not expose any public knobs to manually override the scheme for messaging transports.

pact-foundation/pact-net

1 new commit pushed to

<https://github.com/pact-foundation/pact-net/tree/master|master>

by JP-Ellis

<https://github.com/pact-foundation/pact-net/commit/519d86279daba984b78b2cea1d9da453a7d661b6|519d8627>

- ci: remove unused triage board workflow pact-foundation/pact-net

#559 feat: Add AsyncAPI reference support for message pacts (#557) Pull request opened by mr-roman-vivint Closes #557 Summary Implements AsyncAPI reference support for message pacts (#557) Problem PactNet lacked a way to programmatically add AsyncAPI operation references to message interactions, which is required for PactFlow BDCT with AsyncAPI. Solution Added three new methods to IMessageBuilderV4: •

WithComment(key, value)

- for custom key-value comments •

WithTextComment(comment)

- for text comments array •

WithAsyncApiReference(operationId)

- convenience method for AsyncAPI refs Changes • Core implementation in MessageBuilder and drivers • FFI bindings for pactffi_set_comment and pactffi_add_text_comment • Unit, integration, and E2E tests • Updated sample code and documentation • V4 only (V3 doesn't support comments per spec) Testing All 411 tests passing. Added comprehensive test coverage. Breaking Changes None - additive change to IMessageBuilderV4 only. pact-foundation/pact-net