Sequence of "description" and "providerStates" in messaging provider verification.

[dranidis]

Version information:

• OS: Arch Linux
• PactNet Version: 5.0.1
• .Net Version: 8.0.100
• Pact Broker Version (if applicable): NA

Describe the bug
Description handler is executed before the state handler.

Steps To Reproduce
The current behaviour can be reproduced with the code in this repo: https://github.com/dranidis/pact-dotnet-message-provider

Expected behavior
We have a provider test of an AMQP interaction in Pact. The interaction has a "description" and "providerStates". We added in the test:

.WithMessages(scenarios =>  {
                    scenarios.Add(
                        "scenario description",
                        builder => SetupDescriptionA(builder));
                }, _serializerOptions) ...

and the state handler "prepare data" in the middleware.
I would expect the state handler to execute FIRST to prepare the data for the content of the message, and THEN the description handler to execute SECOND so that it uses a messageProducer function to generate the message based on the prepared data, But it is the opposite!
This forces us to abandon providerStates and only use descriptions for both setting the environment and producing the message.
In case, I misunderstand something please let me know.

[scrocquesel]

Look at this comment, it should help you understand why it is executed in this order.
I think your reproducer should be in the documentation, it is simple and very demonstrative.

[dranidis]

Thanks for the reply and the link to the comment. There is a clear difference between WithContent and WithContentAsync.

The fact that WithContent stores a factory function which is executed AFTER the provider state handler is executed saves the day. I have updated the pact to include 2 interactions sharing the same event description but different providerStates, which is a common case in our applications. The sequence execution is:

Description handler: user was created event
Creating metadata for user creation event
State handler - user registers with email and password
WithContent: user was created event
Creating message for user creation event, email and password registered
State handler - user registers with social account
WithContent: user was created event
Creating message for user creation event, social account registered

The behavior can be reproduced in the main branch of https://github.com/dranidis/pact-dotnet-message-provider

So, indeed we can use the state handlers to prepare the data, and then use the withContent callback to get the correct data for each interaction:

        public void VerifyMessagePacts()
        {
            var verifier = new PactVerifier("MessageProvider");

            verifier
                .WithHttpEndpoint(new Uri(ProviderUrl))
                .WithMessages(scenarios =>
                {
                    scenarios.Add(
                        "user was created event", builder =>
                        {
                            FileLog.Log("Description handler: user was created event");

                            builder.WithMetadata(
                                ProviderStateMiddleware.CreateUserWasCreatedMetadata()
                            );
                            builder.WithContent(() =>
                            {
                                FileLog.Log("WithContent: user was created event");
                                return ProviderStateMiddleware.CreateUserWasCreatedMessage();
                            }
                            );
                        });
                }, new JsonSerializerOptions())
                .WithFileSource(new FileInfo("../../../../../MessageConsumer-MessageProvider.json"))
                .WithProviderStateUrl(new Uri("http://localhost:5000/provider-states"))
                .Verify();
        }

So, although, the description handler is executed BEFORE the providerStates handler, the WithContent handler is executed AFTER the providerStates handler and FOR EACH interaction. This allows us to return messages depending on the provider state. In the example the providerStates handlers change the value of _isSocialAccountRegistered.

    public static object CreateUserWasCreatedMessage()
    {
        if (_isSocialAccountRegistered)
        {
            FileLog.Log("Creating message for user creation event, social account registered");
            return new
            {
                id = 1,
                name = "testuser",
                email = "testuser@mail.com",
                social = true
            };
        }

        FileLog.Log("Creating message for user creation event, email and password registered");
        return new
        {
            id = 1,
            name = "testuser",
            email = "testuser@mail.com",
            password = "testpassword",
        };
    }

The same is not true, however, for the metadata. The function WithMetadata of the builder does not receive a function but static metadata which is set ONCE at THE BEGINNING, not taking under consideration the providerStates. If in the pact we would like to have the messages on different queues, e.g.

    public static Dictionary<string, string> CreateUserWasCreatedMetadata()
    {
        FileLog.Log("Creating metadata for user creation event");

        if (_isSocialAccountRegistered)
        {
            return new Dictionary<string, string>
            {
                { "queue", "user-created-social" },
            };
        }

        return new Dictionary<string, string>
        {
            { "queue", "user-created" },
        };
    }

This is not possible in the current implementation.

It would be possible and probably still save the day if the WithMetadata receives a callback function similarly to the WithContent:

                           // NOT SUPPORTED!
                            builder.WithMetadata(
                                () => ProviderStateMiddleware.CreateUserWasCreatedMetadata()
                            );

[adamrodger]

I think the changes in #536 and #537 are probably what you're looking for to change the meaning of WithContentAsync to make it work more like a callback. It's a breaking change to the API though, so currently those changes have to wait until PactNet 6.x.

As for the metadata, I'm not sure that should work like a callback. If you are expecting different messages on different queues then I'd expect two different interactions are defined, e.g. upon receiving a user creation event via social sign up and upon receiving a user creation event via email sign up. The bodies and queues of those two events appear different, so you'll have an easier time if they were different interactions.

[dranidis]

HI, thanks for the reply!

The changes are definitely towards the correct direction, making WithContentAsync the async version of WithContent.

Concerning the metadata, your suggestion of having two interactions is currently the only way, given the restriction of the current WithMetadata. However, even in that case (although other cases would be also desirable), one would like to verify that the message provider is creating the correct data, e.g. writing the message at the correct queue.

Given the current sequence of "description" and "providerStates", the only way to verify that the metadata are correct is with a callback that would be called after the "providerStates" within a `WithMetadata. With the current implementation the TEST is setting the metadata NOT the message provider.

Therefore, I consider that having a WithMetadata(() => CreateMetadata()) that will call the CreateMetadata at the right time (after the execution of the state handler) is necessary for the correct verification of the message provider.

Otherwise, we are not testing the provider utilizing the whole PACT capacity. I guess, there is a reason that message interactions have contents and metadata. In other languages, where the "providerStates" handlers are called first and the "description" handler afterwards, full verification is possible.

Again, I might be missing something. If there is an example where the metadata are correctly verified, I would be glad to see it.

Currently, the only way to do this is by using some trickery which looks a bit ugly and requires that we use different queues for different messages so that we can set the metadata within the description:

        public void VerifyMessagePacts()
        {
            var verifier = new PactVerifier("MessageProvider");

            verifier
                .WithHttpEndpoint(new Uri(ProviderUrl))
                .WithMessages(scenarios =>
                {
                    scenarios.Add(
                        "user was created event", builder =>
                        {
                            var pactMetadata = new Dictionary<string, string>
                            {
                                {"queue", "sign-up-queue"}
                            };

                            builder.WithMetadata(pactMetadata);
                            builder.WithContent(() =>
                            {
                                var actualMetadata = ProviderStateMiddleware.CreateUserWasCreatedMetadata();
                                actualMetadata.Should().BeEquivalentTo(expectedMetadata);

                                return ProviderStateMiddleware.CreateUserWasCreatedMessage();
                            }
                            );
                        });
                }, new JsonSerializerOptions())
                .WithFileSource(new FileInfo("../../../../../MessageConsumer-MessageProvider.json"))
                .WithProviderStateUrl(new Uri("http://localhost:5000/provider-states"))
                .Verify();
        }