Event ID makes writes idempotent across append operations but not within?

EventStoreDB
1

If I write an event to the Event Store in a single append operation and then follow this up with another event with the same Event ID in a second append operation, then the second event is not written to the Event Store.

All good so far.

If I have two events with the same Event ID written to the Event Store in the same append operation (if I have an array of two events) then both events are written to the Event Store even though they have the same Event ID.

More simply…

Scenario A

Append Event ID 123 (first operation)

Append Event ID 123 (second operation)

= 1 event written to the Event Store (second operation does nothing)

Scenario B

Append Event ID 123 & Event ID 123 (same operation)

= 2 events written to the Event Store (with the same Event ID)

I appreciate Scenario B is something of a mistake on the part of the consumer but it feels like somewhat inconsistent behaviour with respect to the server.

Is this by design and what is the reasoning behind this?

Thanks,

Callum

2

We don't check within a batch as idempotency makes no sense within a
batch. The main purpose is the ability to retry requests. You will
also find odd behaviour (from the outside) if you for instance try
{A,B,C} {C,D,E,F} the whole second batch will be rejected.