You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We use the Pact Broker / Pact webhook workflow, so we publish the Pact file to the broker and the provider verification is triggered via the webhook when the content of the Pact file has changed (on contract_content_changed event).
But unfortunately, the generated and published Pact file differs from test run to test run, as the boundary in the request body that marks the various parts is generated dynamically.
As a result, the Pact broker triggers the provider verification for each consumer build, even though the Pact itself has not been changed (except for the boundary attribute).
Can I set the boundary attribute statically so that the Pact doesn't change?
The text was updated successfully, but these errors were encountered:
marcozet
changed the title
Can I prevent dynamic boundaries on multipart/form-data requests?
Prevent dynamic boundaries on multipart/form-data pacts
Apr 30, 2024
We have a scenario where we need to upload a bunch of files using post with Content-Type multipart/form-data.
So the request body looks like...
and the Pact is generated as...
No issues so far.
We use the Pact Broker / Pact webhook workflow, so we publish the Pact file to the broker and the provider verification is triggered via the webhook when the content of the Pact file has changed (on contract_content_changed event).
But unfortunately, the generated and published Pact file differs from test run to test run, as the boundary in the request body that marks the various parts is generated dynamically.
As a result, the Pact broker triggers the provider verification for each consumer build, even though the Pact itself has not been changed (except for the boundary attribute).
Can I set the boundary attribute statically so that the Pact doesn't change?
I found a similar problem here: pact-foundation/pact-net#410 (comment)
The text was updated successfully, but these errors were encountered: