RC6 messages are sent but are left grayed out

[Gummikavalier]

Description:

Not to be confused with previous issues with grayed out messages.

Quite often, particularly after leaving and returning to a thread, newly sent messages don't finish their animation and are left grayed out.

This issue started in RC6.0.x.

Steps to reproduce:

Prerequisites:
Admin -> General -> REST API -> Use REST instead of websocket for Meteor calls` is turned on. The issue triggers also when using websockets but much more randomly.

Happens in any configuration in RC6.0.1 and RC 6.1.1 as long as you follow the below procedure.

Two users. Two browser windows. (Chrome and Firefox will do.)

1. Create a thread as User1. Thread view mode does not matter (expand or collapse).
2. Send few messages in the thread as User1.
3. Send few messages in the thread as User2. Stay in the thread view.
4. Send one more message in the thread as User1.
5. As User2, close the thread view and return to it.
6. As User2, type a message into the thread.

Variant 2 of the same issue, reproducible with one user by hopping channels:
#28824 (comment)

Expected behavior:

All messages are sent and animate as normal in all situations.

Actual behavior:

Messages are sent but their animation start failing for User2.

When User2 returns to thread again, grayed out messages change slowly their color to black (the animation continues as usual).

At this point any new messages sent by User2 on this thread also fail to animate properly, until revisiting outside of the thread.

The issue continues repeating for that thread until User2 refreshes their session (F5 / reload).

Server Setup Information:

• Version of Rocket.Chat Server: 6.1.1
• Operating System: RHEL8
• Deployment Method: tar
• Number of Running Instances: 2
• DB Replicaset Oplog: Yes
• NodeJS Version: 14.21.2
• MongoDB Version: 5.0

Client Setup Information

• Desktop App or Browser Version: Latest Chrome and Firefox

Relevant logs:

On the very first time when this issue happened in Chrome I got these errors from the F12 -> console.

Auto-Translate is disabled [error-autotranslate-disabled]
(anonymous) @ 2fdd7b8fe210407be6410128d5daae2111607af2.js?meteor_js_resource=true:1636


Deprecated: RoomCoordinator.getRouteData received a room object
getRouteData @ 2fdd7b8fe210407be6410128d5daae2111607af2.js?meteor_js_resource=true:1636

And after verbose switched on:

[Violation] Forced reflow while executing JavaScript took <N>ms
[Violation] Forced reflow while executing JavaScript took 40ms
[Violation] Forced reflow while executing JavaScript took 37ms
[Violation] Forced reflow while executing JavaScript took 40ms
[Violation] Forced reflow while executing JavaScript took 52ms
[Violation] Forced reflow while executing JavaScript took 38ms
[Violation] Forced reflow while executing JavaScript took 36ms
[Violation] Forced reflow while executing JavaScript took 38ms

[Violation] 'requestAnimationFrame' handler took 51ms
6[Violation] 'setTimeout' handler took <N>ms
2fdd7b8fe210407be6410128d5daae2111607af2.js?meteor_js_resource=true:5 [Violation] 'setTimeout' handler took 53ms
2fdd7b8fe210407be6410128d5daae2111607af2.js?meteor_js_resource=true:5 [Violation] 'setTimeout' handler took 51ms
2fdd7b8fe210407be6410128d5daae2111607af2.js?meteor_js_resource=true:1285 [Violation] 'setTimeout' handler took 68ms
2fdd7b8fe210407be6410128d5daae2111607af2.js?meteor_js_resource=true:5 [Violation] 'setTimeout' handler took 50ms
2fdd7b8fe210407be6410128d5daae2111607af2.js?meteor_js_resource=true:5 [Violation] 'setTimeout' handler took 52ms
2fdd7b8fe210407be6410128d5daae2111607af2.js?meteor_js_resource=true:1285 [Violation] 'setTimeout' handler took 85ms
2fdd7b8fe210407be6410128d5daae2111607af2.js?meteor_js_resource=true:1 [Violation] 'setInterval' handler took 71ms
2fdd7b8fe210407be6410128d5daae2111607af2.js?meteor_js_resource=true:1 [Violation] 'setInterval' handler took 103ms
2fdd7b8fe210407be6410128d5daae2111607af2.js?meteor_js_resource=true:1636 [Violation] 'click' handler took 230ms
2fdd7b8fe210407be6410128d5daae2111607af2.js?meteor_js_resource=true:1519 [Violation] 'mousemove' handler took 152ms
2fdd7b8fe210407be6410128d5daae2111607af2.js?meteor_js_resource=true:1268 [Violation] 'blur' handler took 154ms
2fdd7b8fe210407be6410128d5daae2111607af2.js?meteor_js_resource=true:1636 [Violation] 'click' handler took 156ms
2fdd7b8fe210407be6410128d5daae2111607af2.js?meteor_js_resource=true:1393 [Violation] 'message' handler took 172ms
2fdd7b8fe210407be6410128d5daae2111607af2.js?meteor_js_resource=true:1 [Violation] 'setInterval' handler took 66ms

Also then the issue is on, the element still has this CSS in it, so at least partly the browser considers the message being still in pending state (even when it has been successfully sent):

.rcx-message.rcx-message--pending div.rcx-box.rcx-box--full.rcx-message-container div.rcx-message-body div.rcx-box.rcx-box--full.rcx-css-gln5p7

[Gummikavalier]

Note that this issue happened also with one instance alone when we were still using RC 6.0.1. We just started seeing it more now when I switched to REST for meteor calls.

Actually now we figured out how to trigger this consistently, I was able to reproduce this at will in any of the below scenarios:

1. One instance, monolithic setup
2. Two or more instances, monolithic
3. Using REST for meteor calls in above setups
4. Using websocket for meteor calls in above setups
5. RC 6.0.1
6. RC 6.1.1

It is just that usually when people are in the threads they don't neccessarily hop between them and the main view that much when discussion is ongoing.

[Gummikavalier]

@hugocostadev I figured out that in addition to what I described in the original post, this bug triggers a worse condition too, where the thread view stops completely updating for the User2.

This happens when at:

5. As User2, close the thread view and return to it.
6. As User2, type a message into the thread.

User2 at point 5 instead of returning back to the thread, sends a new message to main channel instead of the thread.

At this point animation of post on the main channel view gets stuck too.

From this point onward User2 cannot see any message updates to the thread that triggered it all. They can hear the notification sound and get the visual badge of a new message to other elements in RC, but the thread view lacks any new messages until they do reload / F5 or visit once outside of the thread.
After visiting outside of the thread and back in, User2 can scroll down to see the missing messages. Scrolling down is not possible before closing the thread this second time.

Note that when the this happens on the channel main view, refresh is mandatory; switching to another channel and back does not resolve the issue.

[jdsatava127]

We are experiencing these same issues after upgrading to 6.0.1. We use the Docker image for our installation and are running Mongo 5.0.15.

[dmitriy-olhovsky]

Same problem. Also, sometimes the messages do not display until refresh Rocket.Chat (ctrl + f5).

Version 6.1.3
Apps Engine Version 1.38.1
Node Version v14.14.0
Database Migration 292 (April 17, 2023 20:52)
MongoDB 5.0.15 / wiredTiger (oplog Enabled)

[szktmyk38f]

I have the same problem in my environment.

Rocket.Chat Version: 6.1.2
NodeJS Version: 14.21.2 - x64
MongoDB Version: 5.0.10
MongoDB Engine: wiredTiger
Platform: linux 

[szktmyk38f]

I see that sometimes only notifications are displayed and the corresponding chat does not appear on the channel.
You can finally check it by refreshing with Ctrl + R.

[Gummikavalier]

Preliminary testing with RC 6.2.0 indicates that this issue may have been fixed. I cannot reproduce anymore.

[aprudius]

No, it still persists with RC 6.2.0 :(

[szktmyk38f]

Yes, it still remains. So I downgraded to 5.4.10 and use it. 5.x does not have this bug.

[Gummikavalier]

I still haven't seen and haven't been able to reproduce the issue since RC 6.2.0.

Has anybody found any other steps to trigger it?

[cg-papoo]

We still see it on 6.2.0 6.2.2 (with MongoDb 5.0.18, activated replica set, without DB authentication).

It happens sporadically when jumping between threads.

[krimrise]

I have the same problem in my environment.

Rocket.Chat Version: 6.1.5
NodeJS Version: 14.21.2 - x64
MongoDB Version: 5.0.7
MongoDB Engine: wiredTiger
Platform: Docker

[Gummikavalier]

I saw this happening once again in single instance setup.

We also got reports from our Enterprise multi-instance users that it still happens. Possibly more often there.