feat: Enable Generator type ProviderState

[chad-tw]

Enable generator type provider state.

Now rust is support provider state injection I have proved it on my client project.
I'll write some usage sample probably inside existing EventAPI.

[adamrodger]

I'm not seeing ProviderState type support in the v3 specification?

https://github.com/pact-foundation/pact-specification/tree/version-3#introduce-example-generators

The table there doesn't list ProviderState as an option, and this MR doesn't introduce any of the other options.

[adamrodger]

The spec is a bit of a mess here tbh - only the v4 spec mentions ProviderState as a possible generator type, but says it's supported in v3, even though the v3 spec doesn't mention it....?

https://github.com/pact-foundation/pact-specification/tree/version-4#supported-generators

I'm not really sure what to do about that. At the moment we don't support v4 specs, and the v3 spec doesn't mention this. @mefellows do you have any thoughts?

I'd rather not add partial generator support for something that's not even mentioned in the spec, and at the same time not implement the things that are mentioned in the spec. That seems backwards :)

[mefellows]

@uglyog is probably best qualified to answer here. I thought the mock server URL and provider state generators were v4 but you're right that the spec docs aren't clear on that.

[uglyog]

The different spec versions really only describe the file formats, not so much the behavior. When generators were added to V3, they were designed to be extensible so that new generators could be added in the future.

So while the ProviderState was added after the V3 spec was created, it should still be able to be used with a V3 formatted Pact file.

[adamrodger]

That sounds like a gap in the spec to me though. By mentioning certain generators and not mentioning that it's extensible, it's totally logical to expect that that's a definitive list.

There's no way of looking at the V3 spec as it is now and knowing that there could be anything other than the generator types listed, or what to do if you get a type that's not supported (or even how to know if it's supported or not).

[mefellows]

I think this is more of a misunderstanding of what the spec is. The gap is currently what functional behaviour can be expected across languages. I would argue the spec should be the definitive place for such things.

…

On Mon, 11 Apr 2022, 6:47 pm Adam Rodger, ***@***.***> wrote: That sounds like a gap in the spec to me though. By mentioning certain generators and not mentioning that it's extensible, it's totally logical to expect that that's a definitive list. There's no way of looking at the V3 spec as it is now and knowing that there could be anything other than the generator types listed, or what to do if you get a type that's not supported (or even how to know if it's supported or not). — Reply to this email directly, view it on GitHub <#380 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAANFDGXII75OBQXNIWZIK3VEPRKJANCNFSM5SCLSGLQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>