RocketChat is reloaded when using the channel search

[birdie1]

Description:

When using CTRL+p to open the channel search and perform a search, RocketChat reloads the complete page if searching the channel search. This happens random (all users affected, sometimes it works normal sometimes this issue)

Steps to reproduce:

1. Open channel search with CTRL+p
2. search for a user or channel
3. hit enter to take the first entry

Expected behavior:

After hitting enter the user should be opened.

Actual behavior:

RocketChat hangs for a few seconds, then the whole page is reloaded.

Server Setup Information:

• Version of Rocket.Chat Server: 6.0.0
• Operating System: Debian 11
• Deployment Method: official RocketChat docker
• Number of Running Instances: 1
• NodeJS Version: v14.21.2
• MongoDB Version: 4.4.19 / wiredTiger (oplog Enabled)

Client Setup Information

• Desktop App or Browser Version: both
• Operating System: Linux, Mac, Windows

[Abhishek1274]

Hi @birdie1, can you assign this issue to me as I want to start my open-source contribution

[CulturalProfessor]

Hey @birdie1 I tried to reproduce this issue but it was working fine in my case.

[Gummikavalier]

I also have seen this happen with RC6. Feels random.

[XshubhamX]

@hugocostadev I was able to reproduce it, working on it.

[ulope]

Seeing the same in 6.2.4 and has been present since at least 6.1.x, very likely already since 5.x but can't be certain.
It's INCREDIBLY annoying.

Self hosted instance, has been upgraded through many many versions all the way from around 0.40ish

One factor that seems to influence the chance of this occurring is whether there is only one result or not. With just one result it seems way more likely that the erroneous behaviour occurs than with more than one.

[ulope]

I looked a tiny bit deeper and this seems to be the exception that triggers the reload:

483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1599 TypeError: Failed to fetch
    at r.send (/483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:5:168608)
    at /483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:5:166212
    at /483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1599:967455
    at r.send (/483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:5:168985)
    at /483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:5:166212
    at /483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1599:2095066
(anonymous) @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1599
(anonymous) @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1
Promise.then (async)
n.then @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1366
n @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1599
sendMessage @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1410
_apply @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1410
applyAsync @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1410
(anonymous) @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1410
callAsync @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1410
e @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1599
m @ ServerProvider.tsx:1
(anonymous) @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:5
a.retry @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1599
f @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1268
v @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1268
u @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1268
fetch @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1268
executeFetch @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1268
fetch @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1268
refetch @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1268
onFocus @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1268
(anonymous) @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1268
(anonymous) @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1268
a @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1268
onFocus @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1268
(anonymous) @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1268
(anonymous) @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1268
onFocus @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1268
(anonymous) @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1268
t @ 483a38c4c0addb9b422d114589bd28887f219bf9.js?meteor_js_resource=true:1268

[jmscarpa]

Do we have anything new on that failed to fetch with meteor_js_resource=true ?

[Sayan4444]

I have not been able to replicate this message! Can you check if this issue still persists?

[ulope]

Yes still persists with 6.4.5

It seems to happen slightly less frequently then before but it's always been rather unpredictable when it happens and when not.

[Sayan4444]

Can u please share a video when it happens.....it will be of immense help

Here is how I tried to replicate the issue but failed
https://github.com/RocketChat/Rocket.Chat/assets/112304873/1c5e4c6c-0784-422c-922f-e671eb113eb6

[ulope]

Done: https://youtu.be/gq-BFtdXLYc

[Sayan4444]

Hi @ulope thanks for the video, I guess this issue does not exsists on 6.5, so that maybe thats a reason why I have failed to replicate it

[ulope]

I'll update our server to 6.5 soon and will re-try then.

[Sayan4444]

I'll update our server to 6.5 soon and will re-try then.

Do report me back

[Gummikavalier]

I can still reproduce this in RC 6.5.2 by starting typing a person name (surname) for two or three first letters. Until the fourth letter the selection does not light up, and if you press enter before that reload happens.

It happens only once per search though. To replicate I have to search for some other name and type three first letters of their surname.

[Sayan4444]

@Gummikavalier Can you just record a video and send me back here, it will me super helpful

[Gummikavalier]

@Sayan4444 Not video but these two images show how it happens:

Starting typing the search for the name Tester Fester, after the first three letters the only person that fits the search is exactly who we are looking for. Yet this search result is not selected and pressing enter at this point would reload the web client:

After typing the fourth letter the name becomes selected. If you now press enter, the web client operates as it should:

The real name is Tester Fester. Actual username for this user is testerfester. The user is purely local one to this instance.

There are only ~10 users on this test instance and only few channels, of which no other would hit this particular fes pattern. So the search is not even a big one. The issue should be reproducible with pretty minimal data set.

[Gummikavalier]

I think this may have been fixed in RC 6.6.1.

Edit: Three days of active use and I haven't been able to reproduce the issue anymore.