Indempotency and expectedVersion

EventStoreDB
1

Hi guys,

I’m currently evaluating the event store and I have been trying to write some tests around the idempotency guarantee described in https://github.com/eventstore/eventstore/wiki/Optimistic-Concurrency-&-Idempotence.

According to the documentation saving events with the same stream name and event ID should only create one event. When the ExpectedVersion.Any, saving the event multiple times only creates one event which is great.

However when I save the same event but with incrementing expected version, it creates multiple event. Is this an expected behaviour?

Here’s a snippet of my test which is testing at a low level to ensure it is not my implementation that’s skewing the result.

var eventsToSave = new List { CreateEventData(aggregate) };

using (var connection = EventStoreConnection.Create(ConnectionSettings.Create()))

{

connection.Connect(new IPEndPoint(IPAddress.Loopback, 1113));

connection.AppendToStream(aggregate.GroupId, ExpectedVersion.NoStream, eventsToSave);

// This shouldn’t create a new entry but this line does.

connection.AppendToStream(aggregate.GroupId, 1, eventsToSave);
connection.AppendToStream(aggregate.GroupId, 1, eventsToSave);

connection.AppendToStream(aggregate.GroupId, ExpectedVersion.Any, eventsToSave);

}

var events = EventStoreFactory.Create().GetEventsByGroupId(aggregate.GroupId);

Assert.AreEqual(1, events.Count());

``

The test fails from getting 2 events rather than 1. The first save creates a new stream and an event. The second save creates a duplicate and the third save does not create a new event.

This is a potential problem for us because AFAIK there is no way for me to know if my previous save created an event or not to ensure I don’t increment the version number that I should expect.

Please shed some light.

Thanks,

Ron

2

When using expected version you are telling it what you expect. You should never just be arbitrarily incrementing expected version. Can you explain a bit what you are trying to achieve?

“This is a potential problem for us because AFAIK there is no way for me to know if my previous save created an event or not to ensure I don’t increment the version number that I should expect.”

How could you in a situation where you don’t k ow what you did? Usually version numbers and idempotency/concurrency is all about consistency and handling a retry of an unknown operation. (eg top socket broke)

Greg

3

Hi Greg,

Appreciate your response.

My prototype is slightly different from the repository example you have in GitHub because I am programming to an existing interface which deals with events directly not aggregates and our Aggregate implementation doesn’t currently track its own version number.

As such, my prototype event store instance is required to operate against a single instance of Aggregate and keep the expected version as an instance field. This defaults to NoStream and is updated as events are loaded. When events are saved, the expected version held by the event store instance is passed to the server, and then is incremented by the number of events “saved”. The problem is that the expected number is incremented for each event and the event store seems to create an event every time even though “stream” and “event id” fields haven’t changed.

The Aggregate in the repository example seems to keep track of and increments its expected version when events are produced, that way expected version can be reliably calculated based on number of uncommitted events it has. But I can only prostulate as I don’t have source for the CommonDomain library.

I see your point that the intention of the idempotency is to guard against scenarios such as retries, but what I am wanting to confirm is that the behaviour that I am seeing is an expected one, i.e. if the expected version is different, it creates a new event in the stream. Can you please confirm?

If you see an issue with my implementation/understanding please let me know.

Thanks,

Ron

4

This is 100% expected behaviour. Why are you ending up with the same event written twice with different expected versions? Something sounds very off here. You mention that you update as events are loaded and know the expected versio n at what scenario do you “retry” with a different sequence number?

5

What I was trying to verify was whether or not event store will create duplicates when an exact same events are saved even when a different expected version is specified, in case our infrastructure fails and somehow creates “retries” with a same event but a different version.

Thanks for verifying the behaviour. It’s good to know what to expect in such a scenario.

6

Ya retry should have the same expected version number.