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

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

Version 3.4.0

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

What are you expecting to happen here?

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.

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

No you should just get an idempotent write.

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.

Does the same behaviour happen on 1 and 2?

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

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

yes that was the question

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