Uniqueness of Message subscription ElementInstanceKey

If my process definition has a message subscription, would the elementInstanceKey of message subscription events written by Zeebe onto ElasticSearch (when processes are executed) be guaranteed to be different?

Also, Is the elementInstanceKey guaranteed to be unique per message subscription event across all process instances created on a Zeebe cluster for a same or different BPMN processes?

Hi @ankit_joinwal :wave:

The elementInstanceKey of a MessageSubscription record always refers to the specific element instance that subscription belongs to. So if an intermediate message event is activated and the engine has to wait for the message, then a message subscription is opened for that specific element instance.

Multiple MessageSubscription records are expected to be written for a specific element instance:

  • the CREATE command will be written when the engine wants to open the subscription
  • the CREATED event will be written when the engine has opened the subscription
  • the CORRELATE command will be written when the engine has received a message and wants to start correlating it to a process instance
  • the CORRELATING event will be written when the message can be correlated to the message subscription, and correlation to a process instance has started
  • the CORRELATED event will be written when the message has been correlated to both the message subscription and the relevant process instance.
  • there are also MessageSubscription records for:
    • rejections: REJECT, `REJECTED
    • deletions: DELETE, DELETED

At this time only the events are exported to ElasticSearch, but this might change in the future.

Note that the MessageSubscription may exist on a different partition than the process instance itself. This is why the message subscription is something different than the correlation of the message to the process instance. When the process instance opens the subscription, it does so by writing ProcessInstanceMessageSubscription records on the same partition as the process instance and sending MessageSubscription commands to the partition where the message is expected to arrive (this partition is determined by a hash over the correlationKey). This entire mechanism exists so that we don’t have the write the message to all partitions, which wouldn’t scale. Instead, we deterministically write the message on 1 partition and correlate it to the process instance (which potentially lives on another partition).

Coming back to your original question, we can say that there are multiple MessageSubscription events expected for a specific element instance. If the same element is activated multiple times by the engine, it will be a different element instance with a new elementInstanceKey.

Lastly, we do not offer any guarantees on the exported data, but it’s unlikely that the above description will see major changes.

Hope it helps :slight_smile: