Documentation mismatch on what is expected by the provider state setup url endpoint

[ewortzman]

The documentation for this project for provider states says that the provider state endpoint should accept 2 fields: consumer and state. However, when running pact-provider-verifier with a provider-states-setup-url defined, the actual provider state requests have 3 fields: consumer and state, which are both strings, but also states, which is an array containing the same string that was defined in state.

Looking at the documentation for pact-python, however, implies that my endpoint should be expecting only consumer and states, but not state.

I assume this is a backwards/forwards compatibility thing, and that as pact v2 gives way to v3, the state field will be deprecated, but the differing documentation makes it difficult to know how to implement my endpoint.

Do reproduce the issue:

1. clone this repo: https://github.com/ewortzman/pact-provider-verify-demo.git
2. in one terminal, execute python reflect.py, which will start a simple server that will print the request received to the console, then reply with a 200.
3. in another terminal, execute pact-provider-verifier --provider-states-setup-url=http://localhost:8081/api/_pact/state --provider-base-url=http://localhost:8081 test/pacts/myconsumer-myprovider.json
4. in the output of the reflect server, you'll see the below, which shows that both the state and states fields are present:

----- Request Start -----
/api/_pact/state
User-Agent: Faraday v0.13.1
Content-Type: application/json
Accept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3
Accept: */*
Connection: close
Host: localhost:8081
Content-Length: 64

{'consumer': 'myConsumer', 'state': 'myState', 'states': ['myState']}
-------------------------
127.0.0.1 - - [05/Jan/2018 15:38:48] "POST /api/_pact/state HTTP/1.1" 200 -
------ Request End ------

[bethesque]

Yes, you're right - the array was an attempt to future proof the code in order to get ready for v3. However, what I didn't think about at the time was that the array will actually be an array of objects, as there are extra parameters that come along with the name. So really, you should just stick with the state.

Let's get the documentation updated for the python repo.

[ewortzman]

so will the pact-provider-verifier be updated to remove the states field? Or will that field be updated to be a list of objects, rather than strings?

[bethesque]

It will be updated to a list of objects, with the unfortunate side effect of breaking anyone who is currently using the string list. We'll have to make a clear note of that in the release notes, and it will be a major version release.

[YOU54F]

Tracking via v3 meta issue https://github.com/pact-foundation/pact-ruby/issues/318 so will close this off, with this being the required way forward when we proceed

It will be updated to a list of objects, with the unfortunate side effect of breaking anyone who is currently using the string list. We'll have to make a clear note of that in the release notes, and it will be a major version release.

pact-python will leverage the pact_ffi library, which you can read about here