When we call

Verify

on our

IPactVerifierSource

, we interop into the Rust code which actually verifies the interations. When verifying a given interaction, what is the sequence of events? Specfically, my question is what happens if the interaction is missing the

providerState

key - will it still call the provider states endpoint or will it skip that and go directly to making the request? We're on version 4.1.0 of PactNet if it's relevant.

I think the behaviour previously was not to send a request at all. It is possible that it now always sends a request, whether or not there is a state to handle

hmm, so falls into the realm of undefined behavoiur?

possibly. I’d need to look at the implementation

Previously, we had middleware which checked to see if the incoming request was to the provider-state endpoint - if so, it reset all our stubs and then applied the desired state (and completed the request). If not, processing of the resquest continues as normal. The issue was that for interactions that didn't have a

providerState

key, the verifier was never calling the provider-state endpoint so our stubs didn't get reset - hence stubbing from checking the previous interaction could leak into the next interaction if the next interaction didn't set state itself. We've fixed it for us by changing our middleware to reset the stubs at the end of executing a request that wasn't set-provider-state. It might be better if the verifier always called the provider-state endpoint, even if the interaction doesn't specify a providerState key? It makes the reset/cleanup/set-state more explicit (rather than being done implicitly as a clean-up /

finally

)

Cool, that’s the behaviour I think in the latest core (v0.4.0): https://github.com/pact-foundation/pact-reference/commit/8216ec768d63445b819cffde65e47acc37f4dfcd

@Hoon Jung FYI