Rocket.chat: Channels don't always get marked as read when entered

[Gummikavalier]

Description:

Since Rocket.Chat version 2.0.0 we're experiencing issues where the channels having only few new messages in them don't get marked as read automatically, leaving the channel name as bolded in the channel list pane.

Steps to reproduce:

1. There is a new message on the channel. The channel name has turned into bold to indicate this.
2. The user clicks on the channel and sees the new message on the message pane.

Expected behavior:

The channel should get marked as read and its name in the channel list pane should turn to normal (not in bold).

Actual behavior:

The channel name stays as unread and as bold in the channel list pane.

User can clear this unread status by pressing 'ESC' key to mark the channel as read immediately. Sometimes the this happens automatically when the user waits for a prolonged time (20 seconds), but not always.

In addition to pressing ESC key, also switching tabs in the browser immediately marks the currently open channel as read.

Server Setup Information:

• Version of Rocket.Chat Server: 2.1.0
• Operating System: CentOS7
• Deployment Method: tar
• Number of Running Instances: 20
• DB Replicaset Oplog: Enabled
• NodeJS Version: v8.15.1
• MongoDB Version: 3.6

Additional context

The issue seems to triggers easier on channels that have threads on them.
The issue has been noted on both Chrome and Firefox browsers.
The user amount, server load, disk latency or the amount of memory or cores does not seem to affect the probability of the issue happening.

[stoficek]

I can confirm that since upgrading to 2.0.0 and mongoDB to 4.0.12 messages are not always marked as read.
With upgrading I also migrated rocketchat from Vmware to Proxmox but I dont know if this has something to do with this issue.

[jerbra]

My organization just upgraded this Monday to the latest version deployed via docker-compose and are experiencing the same behavior reported here since the upgrade.

[xbiafra]

Same issue here with 2.1.1 version.

[marcinkorzycki]

+1 on 2.1.1

[waiting-for-rocketchat-fixes]

Same here at my instance ;( 2.1.1

[rjozwiak]

+1 on that

[UsmanArbisoft]

+1. I have to click the options button next to the person/channel name and click 'Mark Read' to make the notification go away. Very annoying.

[lehrhardt]

Updated to 2.1.x this week and seeing this with our user base as well. There is not a really clear pattern when this happens. Our user notice this problem with browser and client on different os.

Pressing "ESC" in the rooms, fixes the problem here too.

[Gummikavalier]

I think that when somebody starts writing on the currently open channel ('xxxxx is typing...' when it wasn't there already at which point that may get stuck too I think), or when some other channel gets a new message, and its position or message amount is changed on the left pane, both of these seem to clear up the unread status of the channel as well. The other two being clicking any other tab or bringing the browser window back to focus.

So the more you have active channels in rocket.chat, and more you switch between different windows on your desktop, the higher is the likelihood of something else refreshing the unread status instead of (assumed) actual timer method purposed for it. This makes this issue seem much less common than what it really is.

[krf]

Still a problem in 2.2.0. No clear pattern when it happens, to be honest.

[rsimai]

I can confirm this for 2.2.0. We see this massively after an update from 1.3.2 where it didn't happen. No clear pattern.

[rsimai]

This is not really a scientific approach but to add more information: It seems to me depending on the browser. I tried with Firefox (68.2.0esr) and Chrome (78.0.3904.97) where Firefox behaves better and most often marks the channel read when I change into it. I fails more often in Chrome. Sometimes it helps to click through random channels and on return it's marked. What always helps to trigger is to change the focus to any other window on my desktop (KDE5, openSUSE Leap 15.1) and back to the browser, then the current channel is automatically marked read even if it wasn't before.

[tholu]

It's a really annoying bug, is there any progress on this?

[Bengrunt]

Still there in 2.3.0.

[antkaz]

Hello! Are there any updates on this issue?

[antkaz]

I think the problem is related with https://github.com/RocketChat/Rocket.Chat/blob/2.3.2/app/ui-utils/client/lib/readMessages.js#L26 because when I open room and wait 2 seconds, the room mark as read. Also if in the room many messages I need open room, wait 2 seconds, scroll up and wait 2 sec again. But if I open the room and don't wait and scroll to up now, the messages don't mark as read

[Wirone]

@antkaz nice hint! It's most probably related to changes in 82ae5034, not sure if this delay time is a problem (it was rised from 1000 to 2000 in this commit), but definitely those changes in marking-as-read logic should be checked again.

[Jason-2020]

This bug is really show stopper. Manually clicking mark as read or switching back and forth few times just to disappear that notification is really annoying. This bug has been there for months, open.rocket.chat users aren't complaining already?

[tholu]

@ggazzo Are you aware of this issue? It's really annoying and users are complaining about it all the time. It is currently the bug issue with most reactions, so please consider fixing this in one of the next releases. Thanks!

[Wirone]

I am wondering if it could be related with massive performance decrease in Android app I'm struggling with for some time already. Very dynamic channels, like automated integrations with external services, are barely usable when entering - for a long time app looks like freezed, after that current messages are re-rendered so date appears between each of them and at the end new messages arrive. Yesterday I left my phone with channel opened and went to do other stuff just to allow app to fetch and process new messages. After sooooome time still not all were displayed (comparing to desktop). Utterly annoying.

[kenmarsh8]

Same issue here, user acceptance is low due to this issue (and others) on web, and the Android App is just unusable.

[ankar84]

Version 2.4.2 still has that bug in place.
Please fix it.

[kenmarsh8]

As a temporary workaround, hit the Escape key instead of using the menu. But, still very annoying.

[valsharess]

I hate to be a nagging nancy but I've deployed several rocketchat instances, standalone and docker and the common problem they have is acknowledging messages as read. Can the logic that was added in 82ae5034 be reverted(or reworked again)? This used to be rock solid and now I have users constantly breathing down my neck.

We've started investigating alternate hosted chat solutions as a result, so I would classify this as very much a show stopper.

@sampaiodiego

[ryguy222]

As a temporary workaround, hit the Escape key instead of using the menu. But, still very annoying.

Sadly this trick doesn't seem to work for us on browser or in the desktop app. This bug is still present in 2.4.3

[zdumitru]

How can this issue be escalated?

[ggazzo]

closed by #16397 any problem let me know :v:

[4lxndr]

@ggazzo why 3.0.0.?

[mddvul22]

3.0.0 is about to release, I believe.

[Wirone]

@ggazzo In our customized RocketChat instance I've cherry-picked this changes to 2.4.7 and unfortunately it does not work... Let's say - it works more than it should, because channels are marked as read even without opening them. New message arrives, channel is for a second marked as unread and then automatically marked as read. I had to revert commit :slightly_frowning_face:

I plan to synchronize with 3.0 but there are major changes in Node versions AFAIS so I personally think it wasn't good decision to target this fix to 3.x, at least it should be ported to 2.x because it was reported on this branch and should be fixed without major changes.

Also, I am not JS/Node/Meteor expert so sorry for dumb question, is it possible to test this behaviour functionally? Flow should be: user has active channel A, new message arrives on channel B and it is marked as unread, user opens channel and it is marked as read.

[valsharess]

I cant speak for trying to backport the changes but its working very well for 3.0.0+, I deployed last week and my users(200) have been very happy.

[Wirone]

@valsharess you've deployed Release Candidate to 200-users instance? Wow, that's quite... optimistic :sweat_smile:

[valsharess]

@valsharess you've deployed Release Candidate to 200-users instance? Wow, that's quite... optimistic 😅

It's a fast paced environment and users not knowing which messages they've read when they have messages from 20+ users is far worse than running release candidate. Ironically I consider these release candidates to be the first functional builds in a while, at least as far as our environment is concerned.

[Wirone]

But on the other hand it's IMO better to not mark messages as read (and force users to use ESC button for example and mark by hand) than auto-marking as read like in our instance... But if RC works for you then :+1: :slightly_smiling_face:

[ggazzo]

sorry @Wirone try cherry pick
https://github.com/RocketChat/Rocket.Chat/pull/16473
https://github.com/RocketChat/Rocket.Chat/pull/16562

[Wirone]

@ggazzo thanks, I've picked changes from #16397, #16473 and #16562, but I think #16442 is most probably what I need - I'll check it and let you know :)

[Wirone]

@ggazzo seems like it's working now :) I need re-pick #16562 as far as I see (from 3.0.0-rc.9).

[ryguy222]

I've upgraded to the 3.0.0. release and am still having issues here.

The counter on the left side does go away when you enter the channel, but the horizontal red line does not go away until you type a message back. Normally ESC key would clear this, or moving to another DM or channel would clear the red bar. Occurs in DM's, Private Channels and Public Channels.

[Wirone]

For those interested in fix for RocketChat 2.* this is patch for 2.4.9 done for our instance and working properly in production since last week.

Includes: #16397, #16473, #16562, #16442 and some cherry-picked changes from 3.0.0-rc.9.

16397-FIX-Rooms-not-being-marked-as-read-sometimes-ported-to-2.4.9.patch.zip (ZIP because GitHub does not support *.patch)

I would like to send it as PR but there is no 2.x branch. @ggazzo do you consider support for older version?

[Bengrunt]

I've upgraded to the 3.0.0. release and am still having issues here.

The counter on the left side does go away when you enter the channel, but the horizontal red line does not go away until you type a message back. Normally ESC key would clear this, or moving to another DM or channel would clear the red bar. Occurs in DM's, Private Channels and Public Channels.

Likewise.
Should a new issue be raised?

[ryguy222]

Likewise.
Should a new issue be raised?

I've opened a new issue, but the behavior seems similar to this one.