-
Notifications
You must be signed in to change notification settings - Fork 10.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Too Many Requests of e2e.updateGroupKey and e2e.getUsersOfRoomWithoutKey #32521
Comments
Thanks for reporting. Which version of Rocket are you using? CE, Starter, Pro etc? How many users? Can you just clarify this?
I will try and get someone to take a look. You will have to try and sanitise some of your logs if they show errors. |
Thanks for your support. We are currently using CE. Logs do not show any errors. Only API call logs. and we have an unrelated error on the rocketchat_uploads indexing conflict. Apart from that, we can't see any errors. |
Is there any update? We have also observed that in peak hours, this issue exists. For example, my client did not send huge amounts of requests before work hours but when people started to log in to RocketChat, my client started to send lots of requests as well. Also, the mobile client does not seems to be effected by the issue. Best regards. |
OK
Seems so.
They show a call to verifyErrors.js Has something odd happened with E2E keys somewhere in the client?
Does this only happen on a client? Or does it occur on a browser too? Are you using just one client app version eg 3.9.14, or different ones?
This is open source. To access immediate support you need to be on a paid plan. Otherwise you will have to wait and see if Rocket take this one up - I think it is likely a support issue rather than a bug. I have tried to ping the team to see if someone will look at it. |
If you searched you would find this |
Also you might want to try latest as it fixes some cache issues and that may be your problem. |
On update,
Some of us are using 3.6.15 and some older versions. I have currently updated it and the issue persists. However, it might be due to other old clients, I am not sure. |
Not sure having a mix of clients is helpful here if you are using E2E.
OK. Chrome or other browser just to be sure? Also are you using GridFS for storage or local storage (just dotting i's here) ? |
I am pushing for updates. Soon we should all be using latest.
Chrome Browser behaves as same.
The server is on a single instance VM that uses local storage. The VM is provisioned in a Cloud environment. |
Thanks for all that. I have asked if someone can take a look. I can't force anyone to do so, but I do think this is worthy of more investigation. I will be watching this bug so no need to @ anyone. |
I have several updates. Firstly, since the app was almost unusable, we took a risk and disabled and re-enabled the E2E from the admin panel. This resolves the issue. However, we are not sure it will not happen again. Secondly, we are a technical team and several of our leads and developers looked into the issue and they strongly think that this is a bug. Thirdly, we observed that the system behaved as expected when most users were offline during off hours. Due to that, ALL of the users do not cause this. Some of the users have issues and they affect all clients. Best regards. |
Thanks for the observations. This is in the hands of the right people, though no promises on a fix - they need to be able to see it/repeat it. |
Description:
After a client update, We have started seeing an increased number of requests on the server (v. 6.5.3). We have updated the server to latest (v6.8.0) and increased the resources on the server. However, none of them solved the issue. While we were debugging, we saw that there were lots of requests from clients to the server. The requests consist of 2 main API calls which are e2e.updateGroupKey and e2e.getUsersOfRoomWithoutKey. In under a minute, a client has sent about 2000 requests. The message IDs in the requests change and are in sequential order.
These huge amount of API requests from the clients are causing saturation on the server even tho we have allocated huge amounts of CPU and RAM to the server.
New and old clients has the issue on latest version of Rocket and in older versions
Steps to reproduce:
I do not know how to reproduce the bug. Before the bug, we had no administrative action on the server. It seems to start after a client update.
Expected behavior:
Limited number of API requests.
Actual behavior:
Server Setup Information:
Client Setup Information
Additional context
Relevant logs:
We cannot provide unsanitized logs in a public channel.
The text was updated successfully, but these errors were encountered: