EventId and Idempotency

EventStoreDB
1

Does the EventStore keep a list of EventIds to avoid inserting the same EventId twice, and so protect the store agains duplicated inserts ?

Cheers,

jeremie / thinkbeforecoding

2

Yes. If you use expected then it’s 100% idempotency. If not its just the last n messages

3

Ok,

but you’re talking about Event number and not EventId (the guid), right ?

jeremie

4

Id is used

5

I tried the following

var e = new EventData(Guid.NewGuid(), “SomethingHappened”, Encoding.UTF8.GetBytes("{Value:42}"), true, null);

var transaction1 = store.StartTransaction(“Stream”, -2);

transaction1.Write(new[] { e });

transaction1.Commit();

var transaction2 = store.StartTransaction(“Stream”, -2);

transaction2.Write(new[] { e });

transaction2.Commit();

and there was no error and the event was written twice… even if it’s exactly the same EventId

jeremie/thinkbeforecoding

6

Let me check it. I know it does on writes but possibly not in transaction (transaction is a bit different)

7

I also tested with appendtostream...

8

Wrote this test:

const string streamId = “idempotency_is_correct_for_explicit_transactions_with_expected_version_any”;

using (var store = EventStoreConnection.Create(ConnectionSettings.Create().UseConsoleLogger()))

{

store.Connect(_node.TcpEndPoint);

var e = new EventData(Guid.NewGuid(), “SomethingHappened”, true, Encoding.UTF8.GetBytes("{Value:42}"), null);

var transaction1 = store.StartTransaction(streamId, ExpectedVersion.Any);

transaction1.Write(new[] {e});

transaction1.Commit();

var transaction2 = store.StartTransaction(streamId, ExpectedVersion.Any);

transaction2.Write(new[] {e});

transaction2.Commit();

var res = store.ReadStreamEventsForward(streamId, 1, 100, false);

Assert.AreEqual(1, res.Events.Length);

Assert.AreEqual(e.EventId, res.Events[0].Event.EventId);

}

Passes test. Second commit should be successful, but it doesn’t append event twice. Same works with AppendToStream, we have a lot of explicit tests for that. Could you describe you test setup?..

9

The event appears several times in the web interface of the stream at least when doing this.

10

Idempotency is meant to work only if you do the same write request with all the same params. So, if you provide different expectedVersions on two write requests, then even if they have events with same IDs, that won’t be idempotent, the try will either fail (if expected version is wrong) or succeed (if expected version is ok). The operation will be idempotent iff you provide, say, expected version 10, then write some other events to stream so stream version becomes 15, then write first event with expected version 10 – then second write with expVer 10 would succeed, but won’t add new events. Please, see my test. You can replace ExpectedVersion.Any with -1 in both writes and it will work. But if you put -1 for first transaction, and 1 for second – event will be added twice, even though event IDs are the same. That makes sense, if you think about that. Idempotency is meant to be used for retrying failed writes due to timeout operations.

Hope this makes the picture clear.

11

Ok,

I just thought there was a check against previous message id guids, so that it would not be inserted anywhere else in the Stream. But I get it now that it is not how it work.

thanks for the info