Currently, these events in queue removal message are ignored as the idea is that correct setting of messageTimeToLive and subscriptionMessageTrackingTimeout should prevent a previous seen event replayed on a client.
However, it failover scenario occurs, a restarted/newly joined member could gii from a secondary HARegionQueue which has those events not removed by the QRM. As the restarted member starts the timer for messageTimeToLive after it restarted. The event could live longer than the messageTimeToLive setting if starts from the original operation time. If this time is longer than the subscriptionMessageTrackingTimeout setting on the client, the client will not prevent the replay of the stray event. This could leads to data inconsistency between client and server.