Do we need a dedicated eventId?

[enikao]

We specify a CommandSource to be a unique identifier for an event.

However, that's not the case: In #306, we have examples of the same CommandSource (called "correlation id" there) being used in several events.

We mention such an example in the spec:

Assume client 1 sends a deleteChild command to delete node X, and then client 2 sends a setProperty command on node X.
...
Repository B keeps an internal "trash can" of all deleted nodes. It deletes node X on the first command, but resurrects node X on the second command and changes the property as requested. It first emits a childDeleted event (correlated to the first command), but later childAdded and propertyChanged events (both correlated to the second command).

Each event does have an EventSequenceNumber that's unique per participation, so each client can identify an event.

Do we need to identify events across participations?

[enikao]

Potential use cases of globally unique event ids:

• Debugging: Correlate events from different clients
  -> add a protocol message

• Later correlation: 2 clients have the same subscription scope, react on an event, and report their reaction to a third party. The third party wants to act once it got the reaction from both clients on the same original event.
  -> add a protocol message

Decision: Don't provide separate event id
Rationale: No clear use case, unclear how unique that event id would be (e.g. unique for the same repo for all time, unique globally, ...)