BUG: unread_messages return incorrect in read state

[thaindangelhack]

In read state, last_read_message_id is always true (with the actual id I marked via API channel.markRead({ message_id: messageId }))
But sometimes, unread_messages return incorrect, always = 0

Some specific cases:

• actual unread_messages > 99: I have 120 unread messages, then I go to the detail screen, the my code will call markRead with the id of the next 15th message (every time I go in details, the default is to call and mark 15 messages as read). When I go back to the list screen, unread_messages should be = 105, but it returns = 0. This error can always be reproduced, please see the video below
• when the last message is a system message
• in some cases, for reasons I don't know, when I actually have 50-60 unread messages, it also returns = 0.

I am using: "stream-chat": "8.14.4", but when I updated to "8.33.1", this bug is still

screen-recording-2024-08-23-at-160958_OByEfuhF.1.mp4

[MartinCupela]

Hey @thaindangelhack , could please share how your channel.markRead call looks like? What params are you passing to the method? Are you using only stream-chat-js or also React or RN SDK? If you use one of those, do you use markRead function provided over the context?

[thaindangelhack]

@MartinCupela Thanks for the quick response.

I'm using:
"stream-chat": "8.14.4"
"getstream": "8.0.1"

[MartinCupela]

Hey @thaindangelhack , the channel.markRead() method does not support passing message id. You can mark only whole channel as read.

[thaindangelhack]

@MartinCupela
So why when I call API with that param, response is still returned success and last_read_message_id is still updated with the correct value passed in param?
Is there any way to mark messages as read by ID?

We want to display the number of unread messages in real time as the user scrolls through the message and code will marks it as read.

[thaindangelhack]

Hey @thaindangelhack , the channel.markRead() method does not support passing message id. You can mark only whole channel as read.

@MartinCupela
I checked again and it's true as you said, this method is not supported, but somehow the previous dev still passed the param and used it.
But I don't think it's the reason why unread_messages is returning wrong (= 0)
Because the value of last_read_message_id is not compatible with unread_messages
=> I think this is a library data storage issue that needs to be fixed

From the library docs i have another way to implement my need:
always call mark the whole channel as read then use the sent messageId and mark as unread. It works now
but there is a limitation from the library: "For performance reasons it's only possible to mark any of the last 100 messages of the channel as unread."
=> I can't keep my unread message count above 100. But this seems to be a good temporary solution with what the library supports

Hope you have a better solution can suggest me. Thanks!!!

[MartinCupela]

Hello @thaindangelhack

1. Regarding this:

But I don't think it's the reason why unread_messages is returning wrong (= 0)

You state this:

the my code will call markRead with the id of the next 15th message (every time I go in details, the default is to call and mark 15 messages as read). When I go back to the list screen, unread_messages should be = 105, but it returns = 0.

If summarized the above statement: 1. call markRead 2. unread_messages === 0. That is expected behavior - marking a channel read, you get 0 unread messages. Could you please explain why do you consider it incorrect?

2. Please explain

last_read_message_id is not compatible with unread_messages

How it is not compatible?

3. Limit of 100 messages marked unread
   This is a back-end limitation that the SDK cannot circumvent.

4. Marking the channel read and then marking the 100th message unread
   You can arrive to a situation when you send a markUnread request with idX, but in the meantime a new message arrives to the back-end and you will end up with error. Also you may reach the API endpoint limit and suddenly will not be able to mark unread. You can easily reach the limit if you want to mark unread on scroll event. I can imagine the UX will be quite bad.

I would recommend not to fixate on functionality that simulates marking individual messages unread.