A stream with one or more events with the same ID - is it allowed?

EventStoreDB
#1

Hey all,

Sorry if derpy question, I checked the docs, github issues and groups but couldn’t find anything. Here I’m appending an event with an expected version to a stream that previously had an event with the same Id appended.

The following appears legal:

This is counter to my expectations. I was expecting line 86 to throw an exception of some sort? (I am not expecting idempotency here). Please tell me I’m wrong :slight_smile:

Cheers,

Damian

#2

Version 3.4.0

#3

Running same eventids can often run into interesting issues. Though why are you doing this?

What are you expecting to happen here?

#4

There was some (internal) discussion recently regarding deterministic event ids so I decided to explore a bit (also Cedar).

I’m not looking to be able to do this. I was expecting something like a unique constraint violation exception that you might get in RDBMS land.

#5

I make no assertions that my expectation is correct wrt EventStore of course :wink:

#6

No you should just get an idempotent write.

#7

I would expect that if the expected version when appending was the same. In my screenshot, I’m using setting the expected version to the current version.

#8

Does the same behaviour happen on 1 and 2?

#9

btw your test is a bit odd as first you say “no stream” then you say “version 0 which it is”

#10

If I append events for expected position 1, then 2?

#11

yes that was the question

#12

Resurrecting this thread as it was not resolved. eg Adding the same message Id to a stream.

I’m synching event stores one in the cloud one in the field - when there are issues and bugs ( eg persist of position didn’t work) I get duplicates which then cause interesting issues… My preferred behavior is that it would do nothing and not add it,

I cant used ver/ concurrency as the message comes from a different store.

Adding again is not great since the quantity of data can be large , eg while most of the time the data is small some synch could bring down 100Mb and I don’t want to read the stream for each message to see if that id was already added… An error would be better than current behavior as it could be ignored /logged as a warning. Then again its probably hard to implement an error / ignore behind the scenes without a read unless I’m missing something…

If I have to read is there an efficient way to get all ids in the stream…

Regards,

Ben