prooph / event-store-http-client

PHP 7.2 Event Store HTTP Client Implementation
BSD 3-Clause "New" or "Revised" License
25 stars 5 forks source link

ResolvedEvent inconsistency #32

Closed enumag closed 5 years ago

enumag commented 5 years ago

I insert data into EventStore and then read the same data by two different ways. There is still something wrong in the link/event distinction. The results should be the same but in fact link/event is swapped in one of them.

I'm not sure which is correct. Anyway there is a bug in one of the prooph repos somewhere. I can dig further but I need a confirmation what is correct first.

Code A: (using HTTP client)

        $slice = $this->connection->readStreamEventsForward(
            'everything',
            0,
            200,
            true,
            $credentials
        );

        foreach ($slice->events() as $resolvedEvent) {
            $link = $resolvedEvent->link();
            assert($link);
            $event = $resolvedEvent->event();
            assert($event);

            $output->writeln('link: ' . sprintf('%s@%s', $link->eventNumber(), $link->eventStreamId()));
            $output->writeln('event: ' . sprintf('%s@%s', $event->eventNumber(), $event->eventStreamId()));
        }

Code A result:

link: 0@CodeListsManagement.ZipCode-7ad864ae-88bc-d948-87ce-973e0fbb8a73
event: 0@everything
link: 0@CodeListsManagement.ZipCode-19b8f7cb-5146-144c-aa01-cac23e670a4d
event: 1@everything
link: 0@CodeListsManagement.UnitAttribute-963a08a3-4640-5e47-9fe2-fb2143b338d6
event: 2@everything
link: 0@CodeListsManagement.UnitAttribute-f4c82854-49e6-4b46-ba89-263867c5f1ea
event: 3@everything
link: 0@CodeListsManagement.UnitAttributeSet-d7c15e02-5caf-4dd5-bac3-b3746cb2c954
event: 4@everything
link: 1@CodeListsManagement.UnitAttributeSet-d7c15e02-5caf-4dd5-bac3-b3746cb2c954
event: 5@everything
link: 0@CodeListsManagement.FeeName-27858a0b-ab34-ea4e-9f10-04336e9c6ce2
event: 6@everything
link: 0@CodeListsManagement.FeeName-5c31c488-8f47-1a4a-a468-8992771ed332
event: 7@everything
...

Code B: (part of my persistent subscription testing, using TCP client)

    private function createEventAppearedHandler(OutputInterface $output): EventAppearedOnPersistentSubscription
    {
        $callback = function (
            EventStorePersistentSubscription $subscription,
            ResolvedEvent $resolvedEvent,
            ?int $retryCount = null
        ) use ($output): Promise {
            $link = $resolvedEvent->link();
            assert($link);
            $event = $resolvedEvent->event();
            assert($event);

            $output->writeln('link: ' . sprintf('%s@%s', $link->eventNumber(), $link->eventStreamId()));
            $output->writeln('event: ' . sprintf('%s@%s', $event->eventNumber(), $event->eventStreamId()));

            return new Success();
        };
    }

Code B result:

link: 0@everything
event: 0@CodeListsManagement.ZipCode-7ad864ae-88bc-d948-87ce-973e0fbb8a73
link: 1@everything
event: 0@CodeListsManagement.ZipCode-19b8f7cb-5146-144c-aa01-cac23e670a4d
link: 2@everything
event: 0@CodeListsManagement.UnitAttribute-963a08a3-4640-5e47-9fe2-fb2143b338d6
link: 3@everything
event: 0@CodeListsManagement.UnitAttribute-f4c82854-49e6-4b46-ba89-263867c5f1ea
link: 4@everything
event: 0@CodeListsManagement.UnitAttributeSet-d7c15e02-5caf-4dd5-bac3-b3746cb2c954
link: 5@everything
event: 1@CodeListsManagement.UnitAttributeSet-d7c15e02-5caf-4dd5-bac3-b3746cb2c954
link: 6@everything
event: 0@CodeListsManagement.FeeName-27858a0b-ab34-ea4e-9f10-04336e9c6ce2
link: 7@everything
event: 0@CodeListsManagement.FeeName-5c31c488-8f47-1a4a-a468-8992771ed332
...
enumag commented 5 years ago

In case you don't see the difference compare

link: 0@CodeListsManagement.ZipCode-7ad864ae-88bc-d948-87ce-973e0fbb8a73
event: 0@everything

with

link: 0@everything
event: 0@CodeListsManagement.ZipCode-7ad864ae-88bc-d948-87ce-973e0fbb8a73

These should be the same since there is no difference in my code that handles the ResovedEvent.

EDIT ... I might have accidantly swapped the results. Still doesn't change the fact that there is a bug.

EDIT 2 Yeah they were swapped, fixed now.

enumag commented 5 years ago

Btw. I think we should change the docblocks of ResolvedEvent. I still don't understand what is supposed to be in event/link/originEvent after reading them.

Basically we have some events in many separate streams, right? Let's call these X events (data of X event is typically a json). Then we have a projection that aggregates those streams and creates a new streams with links - let's call these Y events (data of Y event is identifier of a X event).

Now ResolvedEvent should contain both X and Y event but I'm not sure which method of ResolvedEvent should return X and which should return Y.

It definitely doesn't work that way though because in current implementation both link() and originEvent() return the same thing.

What is your understanding? Can you give me your pairing of event/link/originalEvent to X/Y? If you do I think I can send a PR to solve both the docs and the bugs.

enumag commented 5 years ago

From gitter: intended pairing is

prolic commented 5 years ago

fixed by ed752df