devlikeapro
[BUG][NOWEB] - Sessions crashing and changing status abnormally
Hello, I integrated with the Waha api 2 weeks ago using the NOWEB engine and it ran without any problems for around 400 sessions. Since we were forced to update to version 2024.5.8 we started having problems with the session dropping from WORKING status to SCAN_QR_CODE status. Last night at around 10:30 pm (BR) we updated to version 2024.5.9 thinking that this problem would have been resolved, but today the same thing happened. Today we had around 400 WORKING sessions and at around 4pm (BR) more than half of the sessions fell to SCAN_QR_CODE. Yesterday we identified that when dropping a session (LOGOUT) other sessions dropped together. We are receiving many complaints from our customers and do not intend to change platforms, which is why we ask for some urgency in resolving this issue. I'm sending some log and dashboard images for analysis.
Yours sincerely, Abel Genial
@abelgenial hi!
Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory (4131.3) MB
Could you check the memory usage for the server please, does it have enough free memory? This is what in the logs interesting
What version did you use before, do you remember by any change? Wanna compare changes, may be will find smthg
Could you check 2024.5.11
- Increased heap size to 16GB (it doesn't mean that your server must have that amount, but it's better to have some free memory always)
- Pinned nodejs version to the previous one (one that was 2 weeks ago)
If it repeats with that - likely there's some memory leaks in the code :( Also the server memory usage graph would help here!
400 sessions in one container - that's good, but kinda dangerous I see :D Consider splitting it to 4 containers, so the sessions don't affect each other so much. May be a single session has some issue, but it affects all 400.
Waiting for your feedback!
Hello, as per the attached print: node 20.12.2 Server memory 48 GB, 14 GB in use At the moment we only have 157 sessions, as it takes a while for everyone to read the QrCode again. The version that was running well was 2024.5.3 as shown in the attached print, I even had 514 sessions running very well because my server has the capacity to work with that volume. We have used the NOWEB engine since the beginning because we found that the WEBJS engine consumes 4x more of the server. Yesterday, we also detected that when stopping the container and starting it again, some sessions that were WORKING do not start working again, remaining in SCAN_QR_CODE. We will then update to version 2024.5.11 according to your feedback. Regarding your suggestion of dividing into 4 containers, it may not be necessary, since the api has already proven that in version 2024.5.3 it supports it perfectly and this worked uninterruptedly for a week.
Hello, here is feedback on the update process from version 2024.5.9 to 2024.5.11
I stopped docker deletes images and container I updated version 2024.5.11
I opened the dashboard and 60 sessions appeared in scan_qr_code mode that were working
We will monitor during the day and inform you, as previously stated, version 2024.5.3 was completely stable.
Thanks
Hi! Could you send the logs for that restart to see why they got unauthorised please!
пт, 24 мая 2024 г., 20:04 abelgenial @.***>:
Hello, here is feedback on the update process from version 2024.5.9 to 2024.5.11
I stopped docker deletes images and container I updated version 2024.5.11
I opened the dashboard and 60 sessions appeared in scan_qr_code mode that were working
We will monitor during the day and inform you, as previously stated, version 2024.5.3 was completely stable.
Thanks
WhatsApp.Image.2024-05-24.at.10.01.14.jpeg (view on web) https://github.com/devlikeapro/whatsapp-http-api/assets/68116816/f4113eb1-4790-4167-9055-75cfab1fd7a6
[image: patron:PLUS] https://waha.devlike.pro/docs/how-to/plus-version/#tiers
— Reply to this email directly, view it on GitHub https://github.com/devlikeapro/whatsapp-http-api/issues/347#issuecomment-2129491384, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBMR3SWVNQZR6I4SVH6JA3ZD43HXAVCNFSM6AAAAABIGTJ7SKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRZGQ4TCMZYGQ . You are receiving this because you commented.Message ID: @.***>
Today I can't do it, next week I will delete the log and do this procedure and send you the logs generated after this procedure, in case some sessions return as Scan_qr_code. Is there any way to disable the recording of the qrcode (figure) in the log to make it smaller? Thanks
Hello, many sessions change status alone according to attached images without any type of action in Docker or on the server. The status of several sessions is also changed from working to scan_qr_code after stopping docker and starting it again. I did the test even more completely. I stopped docker, deleted containers and images and re-updated the 2024.5.11 version and re-created the containers and I could see that several sessions changed from working status to scan_qr_code, see log. I also noticed that when disconnecting a session, sometimes other sessions change status to scan_qr_code and even stopped.
I would like to know if it is possible to return to version 2024.5.3 as some change since then is causing this serious error in the sessions. I would also like to say that this is happening with a few sessions, it is not necessary to have 200 sessions so that the sessions are not reset as working.
20c24c3d06960e36bbe872f7b3a960f9eb6c0ea8ad6da8cfb50158a691ebce01-json - Copia.log
At 16:45 BR I deleted the 170 sessions status scan_qr_code and one of them was stopped (before the deletions, no session was stopped) and I can't delete it even from the dashboard, see images.
Could you the permissions for .sessions/noweb/{SESSION} folder? looks like docker changed it a bit
you can quick fix it by chmod 777 -R .sessions and try to delete the session again
For file storages - found the problem in the engine and created a PR to fix it in general.
Meanwhile, added a quick fix solution in 2024.5.12 WAHA Plus version.
For mongodb issue need to look at this properly, make sure you're using this installation right
:warning: if the current version works better (not 2024.5.12 one) - let's use this until the proper fix
The quick fix in 2024.5.12 solved the issue, right? @abelgenial
We added the proper solution in 2024.5.14, so it doesn't broke the files at all, feel free to update later (it's not urgent)
I saw that you released the new version 2024.6.1, what do you recommend and what are the biggest news?
Hi! You can check the changelog and see if it's required for you to update https://waha.devlike.pro/docs/overview/changelog/
We add Build: 2024.6.1 in all records