Multiple onContactUpdate Calls When Loading Historical Messages in Tinode SDK

[shc0801]

Tinode SDK Bug Report

Describe the bug

When executing a query to fetch messages using withLaterData(MESSAGES_PAGE), the onContactUpdate callback in the 'me' topic is being called multiple times with 'msg' and 'read' status for each message in MESSAGES_PAGE. This seems excessive and potentially unintended behavior.

Question

Is this the expected behavior of the SDK or am I implementing something incorrectly? Looking at the source code, I see that _refreshContact is called for each message in _routeData, but I'm unsure if this is intended or if there should be a way to batch these updates when loading historical messages.

To Reproduce

Steps to reproduce the behavior:

1. Initialize a chat room component
2. Execute the following code:
   `
   let getQuery = currentTopic.startMetaQuery();

getQuery = getQuery.withLaterData(MESSAGES_PAGE);
if (isReader.value) {
getQuery = getQuery.withLaterDel();
}

await currentTopic.subscribe(getQuery.build());
`

3. Observe the console logs showing multiple calls to onContactUpdate
   Expected behavior
   The onContactUpdate callback should be called only once for the batch of messages, not for each individual message in the page.
   Environment:
   SDK Version: Tinode JS SDK
   Browser: Chrome
   OS: Windows 10
   Console log:
   tnMeContactUpdate msg tnMeContactUpdate read tnMeContactUpdate msg tnMeContactUpdate read tnMeContactUpdate msg tnMeContactUpdate read ... (Repeats MESSAGES_PAGE times)

Code Analysis
The issue appears to stem from how message updates are propagated in the SDK:

1. In topic.js, each message triggers:
   this._tinode.getMeTopic()._refreshContact(what, this);
2. This leads to multiple calls to onContactUpdate in the 'me' topic:
   _refreshContact(what, cont) { if (this.onContactUpdate) { this.onContactUpdate(what, cont); } }

Question

Is this the intended behavior of the SDK? If not, should there be a mechanism to batch these updates when loading historical messages?

Additional context

This behavior impacts performance and causes unnecessary UI updates when loading message history. A potential solution might be to batch these updates or handle them differently for historical message loading vs real-time updates.

[or-else]

Not sure. Try disabling it and see what breaks.