List provider states

[bethesque]

Re-using existing provider states can allow a new interaction to be successfully verified without having to make a change to the provider code. It is currently not easy to get a list of all the provider states for a particular provider. A new endpoint/CLI command would make it easy to discover and reuse provider states.

Potential usage:

pact-broker list-provider-states --provider Bar --branch main

NAME                                | CONSUMER
------------------------------------|---------
there is an alligator named Mary    | Foo1
                                    | Foo2
a bar exits                         | Foo1

pact-broker list-interactions --provider Bar --branch main --provider-state-name "a foo exists"

consumer: Foo1
providerStates: ...
request:
  method: "GET"
  path: "/foos"
response:
  status: 200
  body: ...


consumer: Foo2
providerStates: ...
request:
  method: "POST"
  path: "/foos"
response:
  status: 201
  body: ...

pact-broker list-interactions --provider Bar --branch main --provider-state-name "a foo exists" --consumer Foo

<as above but filtered by consumer>

pact-broker list-interactions --provider Bar --branch main --provider-state-name "a foo exists" --request-path "/foos" --request-method "POST" --response-status 200 --request-body "foo" --response-body "bar"

<as above but filtered>

[mefellows]

Want. I get this request frequently in calls with customers/prospects. A view of this in the Pactflow UI would also be really nice.

Related to this, perhaps more difficult, would be the ability to see the current "interface" expected by the provider team. i.e. the union of all contracts.

[bethesque]

current "interface" expected by the provider team. i.e. the union of all contracts.

I deliberately didn't mention that because I don't know how to do it!

I think at one stage though, we speculated about returning the entire provider response in the test results, so you could see not only what the consumer expected, but also what extra fields were available.

[mefellows]

:)

I think at one stage though, we speculated about returning the entire provider response in the test results, so you could see not only what the consumer expected, but also what extra fields were available.

Yeah, that would be nice!

But just initially, I'm not referring to what the provider can do, but what it is required to do, by virtue of the union of the consumer contracts, which I assume is an extension of the feature you are talking about.

As for the other solution, I imagine we would need to collect these samples separately (or perhaps that relates to the other instrumentation features we've discussed/imagined).

[trickKaluza]

I'm also interested in this feature. We'd like consumers to be able to self-serve test creation. At present there isn't a way for them to know which states are supported by the provider, or what values are returned in the provider-state callback. I was hoping the broker would keep a copy of the registered states, perhaps on publish of a new provider version. This would allow consumers to query what's already available, as well as know what values to pull into their requests via fromProviderState or similar.

[trickKaluza]

See thread in slack: https://pact-foundation.slack.com/archives/C9VPNUJR2/p1731511593857449

[trickKaluza]

In the meantime we may leverage the [null] state handler to throw errors that contain this information, but it's an unpalatable option.