Jaruyot Trithipakij
11/24/2025, 6:36 AMroom(id: "123")), and these IDs are recorded in the pact.
• When we run provider verification, those IDs usually don’t exist in the provider’s real database.
• We have a provider state setup tool that runs mutations to create test data, but the provider uses identity/auto-generated IDs, so the IDs returned from setup don’t match the hardcoded IDs in the contract.
Conceptually, we’d like to:
1. In provider state: run a mutation to create test data and let the provider assign an ID.
2. In verification: use the ID returned from setup in the GraphQL request for that interaction.
Questions:
1. Is there any supported way in Pact for provider state output (e.g. a newly created ID) to influence or substitute into the request during provider verification?
2. If not, what’s the recommended way to handle this pattern of:
◦ Consumer/UI tests that send static/example IDs
◦ Providers that rely on auto-generated identity columns?Matt (pactflow.io / pact-js / pact-go)
1. Is there any supported way in Pact for provider state output (e.g. a newly created ID) to influence or substitute into the request during provider verification?I believe Pact .NET doesn’t currently support that, see https://github.com/pact-foundation/pact-net/issues/385
Matt (pactflow.io / pact-js / pact-go)
1. If not, what’s the recommended way to handle this pattern of:
◦ Consumer/UI tests that send static/example IDs
◦ Providers that rely on auto-generated identity columns?Unfortunately, we usually expect to be able to fully control the provider side during verification - usually this is achievable through stubbing or other unit-test level interventions.
Jaruyot Trithipakij
11/24/2025, 7:25 AMMatt (pactflow.io / pact-js / pact-go)
Matt (pactflow.io / pact-js / pact-go)
Jaruyot Trithipakij
11/25/2025, 3:00 AMMatt (pactflow.io / pact-js / pact-go)
Jaruyot Trithipakij
11/25/2025, 5:51 AM