Cannot filter livechat history messages with "ts" queryparameter

[t0bbz0n]

Description:

Not possible to use "ts" query parameter to filter livechat history messages. Parameter is ignored.

Steps to reproduce:

1. As a guest, open a new live chat.
2. Send a couple of messages
3. Using the REST API to load the Livechat history and specify the "ts"parameter to only retrieve the latest message

Example: https://myserver.rocket.chat/api/v1/livechat/messages.history/myroomid?token=guestToken&ls=2021-02-19T12:39:53.746Z

Expected behavior:

The history should only return messages AFTER the given timestamp.

Actual behavior:

All messages are returned.

Server Setup Information:

• Version of Rocket.Chat Server: 3.10.5
• Commit: 1e36f4183852248cece3b1ad092bc566a8cfbd52
• Operating System: Linux
• Deployment Method: Cloud
• Number of Running Instances: 1
• DB Replicaset Oplog: wiredTiger
• NodeJS Version: v12.18.4
• MongoDB Version: 4.2.8
• Deployment ID: uMe4Y5PA8XksWcbRr

Client Setup Information

• Desktop App or Browser Version: Chrome
• Operating System: Windows 10 1803

Additional context

If there is no magic that I don't see the parameter is actually called ls (found here but called ts in the documentation.

Either way, neither of the parameters does anything.

Not sure if the documentation is missing something or if I'm doing something wroing.

[paurkedal]

I hit the same issue using the realtime API. It looks like the ls parameter of the loadMessageHistory function only affects the unreadNotLoaded count of the result. I found the following workaround, or maybe it's the right way of doing it:

• Fix the end time to the current time so that the results of the following two call will be stable.
• Perform the search with count = 1.
• If unreadNotLoaded from the result is greater than 0, redo the search with count = unreadNotLoaded + 1.

This gives only new messages, and not messages updated since the last session, but maybe that's sufficient here, given the mention of ts in the title? (In my case I also need messages which have been updated since the last session, in which case the only solution at the moment seems to be to load the full history on startup.)