App users (cc @ara4n) have reported that a message sent in the EX apps would "bounce" on screen: first appear, then disappear and reappear quickly, after a short amount of time.
#6397 shows this behavior in a test. After sending the event, it is saved in the send queue (making the bouncing behavior a fallout of #5920). The event timeline item state moves from not-sent-yet to sent, with the same TimelineUniqueId. After the remote echo has been received from sync, the event is deduplicated in the event cache, so the updates that are triggered are the following:
- delete the duplicate event (
Remove vector diff update)
- insert it back at the expected position (
PushBack / PushFront / Insert vector diff update)
Even though the reinserted item reuses the same TimelineUniqueId, it might not be sufficient for embedders to detect that this is a Set in disguise, so the event is first removed from the timeline, and then reinserted.
I think that to properly handle such a case, we'd need some kind of position-aware deduplication mechanism: identify a common head and tail between a list of known events and a list of new events, which would avoid Remove/Insert sequences, so we can turn them into Set instead.
App users (cc @ara4n) have reported that a message sent in the EX apps would "bounce" on screen: first appear, then disappear and reappear quickly, after a short amount of time.
#6397 shows this behavior in a test. After sending the event, it is saved in the send queue (making the bouncing behavior a fallout of #5920). The event timeline item state moves from not-sent-yet to sent, with the same
TimelineUniqueId. After the remote echo has been received from sync, the event is deduplicated in the event cache, so the updates that are triggered are the following:Removevector diff update)PushBack/PushFront/Insertvector diff update)Even though the reinserted item reuses the same
TimelineUniqueId, it might not be sufficient for embedders to detect that this is aSetin disguise, so the event is first removed from the timeline, and then reinserted.I think that to properly handle such a case, we'd need some kind of position-aware deduplication mechanism: identify a common head and tail between a list of known events and a list of new events, which would avoid
Remove/Insertsequences, so we can turn them intoSetinstead.