Why am I getting an ENTITY_CHANGED event on a loser entity after a merge has occurred?

Question

We found an entity where the first two entities got merged and the next update was made on the entity which is already lost in the merge event, hence the entity changed the event message posted on the loser entity URI.  This is incorrect, the changed event should be posted to the winner URI.

On the first occurrence, GmRsdtH and 1gXG8a0k merged together on 05/04/2022 at 04:43: 29am. After the merge event,  The winner entity URI is GmRsdtH and the loser entity URI is 1gXG8a0k.

On the second occurrence, the new update was posted on the crosswalk part of 1gXG8a0k URI at 05/04/2022 4:43:52 AM.  Since 1gXG8a0k is already merged with GmRsdtH, the next ENTITY_CHANGED message has to be posted on the GmRsdtH URI but it is posted on the loser entity URI (1gXG8a0k)

Answer

• AWS does not guarantee the sequences, so you may receive the messages in an unexpected order. 
• In the documentation in https://docs.reltio.com/events/eventsapi.html, you will notice that the platform streaming functionality works with at least one message delivery semantic.  The reason for this is because the service that we use (AWS) provides “At-least-once delivery“ so there are chances of duplicate messages.
• If this occurs, the copy of the message isn't deleted on that unavailable server, and you might get that message copy again when you receive messages.   You can address this problem by designing your applications to be idempotent (they should not be affected adversely when processing the same message more than once).”  ( as defined in Amazon SQS Standard queues - Amazon Simple Queue Service).    
• We can change your physical storage property setting to capture objectVersion and commitTime in your event messages (as demonstrated below).

 "JMSEventsFilteringFields": [
          "startObject",
          "updatedTime",
          "commitTime",
          "objectVersion",
          "updatedBy",
          "createdBy",
          "createdTime",
          "attributes",
          "type",
          "uri",
          "endObject",
          "VeevaSync"
      ],

• Please consider reviewing the documentation in https://docs.reltio.com/events/messagestreamingcrud.html  regarding the use of objectVersion rather than a timestamp.

Make sure to use the objectVersion header to order the events of the same object instead of using fields that have timestamps, such as createdTime, updatedTime or any fields that originate from the crosswalk. The messages contain the header only if it is included in the JMSEventsFilteringFields property based on the message streaming configuration. The header value is an incremental number, which is updated after every change in the business object. So, the message with the highest objectVersion header value will contain the latest object state.

• With the change to your physical tenant storage,  you should see the proper sequencing of events. 

entityId=l1TkFnC, oktaId=00u4w23pxoEjs32s24x7, commitTime=1634927970072, objectVersion=4000000000
entityId=l1TkFnC, oktaId=00u4w23pxoEjs32s24x7, commitTime=1634927970072, objectVersion=3000000000

• As you can see below the commitTime is applied in the JSON body of the event message.

{
    "type": "ENTITY_CREATED",
    "object": {
        "uri": "entities/1xL5JAbV",
        "type": "configuration/entityTypes/Individual",
        "createdTime": 1654009552864,
        "updatedTime": 1654009552864,
        "attributes": {
           "PersonId": [
                {
                    "type": "configuration/entityTypes/Individual/attributes/PersonId",
                    "ov": true,
                    "value": "72412641",
                    "uri": "entities/1xL5JAbV/attributes/PersonId/8qtNlvtqP"
                }
            ],
            "ID": [
                            {
                                "type": "configuration/entityTypes/Individual/attributes/Identifiers/attributes/ID",
                                "ov": true,
                                "value": "10492107700",
                                "uri": "entities/1xL5JAbV/attributes/Identifiers/8qtNloopp/ID/8qtNloxML"
                            }
                        ]
                    },
                    "ov": true,
                    "uri": "entities/1xL5JAbV/attributes/Identifiers/8qtNloopp"
                }
            ]
        },
        "commitTime": 1654009552864
    }
},

•  The SQS message is broken down into two parts - attributes and the JSON body.   The "objectVersion" is defined in the attribute section and the "commitTime" is defined in the body of the event message.

Reference