Hi @Matt (pactflow.io / pact-js / pact-go) @rholshausen, I've been trying out the

valueFromProviderState

enhancement and found that injecting singular primitives works fine however injection of a collection from state provider isn't supported (example: a list of strings). Would it be possible to add such support as well, at least for primitive types?

Seems plausible, but I’d need Ron to give some idea of effort here. What’s the use case?

in my case I need to inject a list of strings that are created at the

@State

Not a trivial change, and will have to be implemented in both Rust and Pact-JVM to keep it constant.

is this currently supported in the REST stack?

No

I meant

valueFromProviderState

mentioned here

That will only work for JSON, because JSON is not a well-structured format, and the provider state handler returns JSON so the values can be blindly injected. With Protobufs, that can't blindly work, the values have to transformed to match the Protobuf messages.

so what will it take to start working on this?

First, you should create a GitHub issue for it, otherwise this conversation will get lost (unpaid slack has limited chat history)

Hi Eran! Usually we review open issues in the Pact ecosystem every few weeks, and pull into PactFlow’s backlog if it’s something we don’t think the OSS community / maintainers will pickup (see https://docs.pact.io/help/smartbear) and we believe it’s something that should be implemented/fixed. We then review in our own internal planning and schedule that way. Usually, new features/capabilities would have a longer lead time unless there’s a break in activity or (in the previous case) somebody is able to pick it up right away in-between other work

Oh, I see, I just thought this belongs under the Add support for fromProviderState generator ticket you created

Hi Eran, apologies I missed this. I’ll bring it into our sprint for review and discussion (this happens next week). Ron (the JVM / core lead) has also been on leave and returns next week, and his input here will be needed.

I just saw that you tagged it with

smartbear-supported

which from my previous experience means that you are working on it. Thanks! 🙂

Hi Eran, I’m afraid we haven’t had any time to review or plan any changes around this. We are currently tied up with a few major initiatives. Also sorry I missed your other message:

I just saw that you tagged it with

smartbear-supported

which from my previous experience means that you are working on it. Thanks!

this means it gets moved into an internal tracker at SmartBear. Any updates will still be made public, including if we are going to pick up and work on it etc. I imagine further clarification would need to happen on this before it’s picked up.

Hi @Matt (pactflow.io / pact-js / pact-go), we have a large application with a lot a legacy REST endpoints (some of which already have a form of contract testing) that we decided not to port to Pact right now due to cost (known issue with Pact) but might invest into in the future we decided to start with Pact over gRPC endpoints that we don't currently have coverage for however a lot of them need collections injected via

valueFromProviderState

so this is a blocker for us to adopt Pact as a whole

Hi Eran, I understand. Ron has started to look into this. If he has any questions he’ll reach out via GitHub.

I'm nearly done, but something high-priority has come up, so I won't be able to finish this until some time next week

I don't have a dev. environment setup for this but if need be I'll make that happen

Otherwise I can just release a new version, I just thought it would be better to release one that is known to work

I pulled the latest plugin code, built it and copied it to my runtime folder I can see the correct values generated at the state setup injected at test time 👍

Fantastic - thanks Ron (and thanks for confirming Eran)