Sometimes whatsapp-web.js hangs and stops receiving messages

[angmon73]

Is there an existing issue for this?

• [X] I have searched the existing issues

Describe the bug

I use whatsapp-web.js for a local radio; it is set to just receiving messages, no sending to anyone. It is running on a Ubuntu 20.04 machine with 16 GB RAM. It receives almost 1000 messages per day and it worked flawlessly for months. Starting from half of june, sometimes (two - three times a day) it hangs receiving messages without any error message. It just stops running and it cannot receive any new message. To reset it, I must close the running program, delete the session file (.webjs_auth) and start it again. When this problem occurs, if I don't delete the session file, the program doesn't login at the new starting, but whenever I stop the program and restart it normally (not after an hang), it logs in normally using the existing session file. It seems no matter about huge video or media downloads; with the progam running, I tried to send a 30 MB video and it was normally received. I have the same library version (1.16.6) installed in a second server with a second whatsapp number and it seems not to suffer of the same problem.

Thank you in advance Any help will be appreciated

P.S. Is there a way to check the current library version? P.S.2 What is the currect way to upgrade to the 1.17 versione?

Expected behavior

The expected behavior is no hangs in receiving messages.

Steps to Reproduce the Bug or Issue

I'm not able to reproduce the bug. Sometimes it happens, but I don't know why

Relevant Code

No response

Browser Type

Chromium

WhatsApp Account Type

WhatsApp Business

Does your WhatsApp account have multidevice enabled?

Yes, I am using Multi Device

Environment

OS: Ubuntu 20.04 Phone OS: Android 22 whatsapp-web.js version: 1.16.6 Node.js version: v14.19.1

Additional context

No response

[telmedola]

Same here. And sometimes, google is closed without warning. The event 'disconnected' not triggering.

[shirser121]

Same here

[bagojikop]

yes , I am also facing the same issue

[bernardoely]

same issue here. Any clue?

[almando]

i have same issue. Any clue?

[omarmyousef]

@pedroslopez please maintenance this issue, emitting "disconnected" or other specific event would make it easier to restart the browser when this happens

[smilingOrange]

This happens to me sometimes when the Internet connection is broken.

Last message time : 1658551323 ||| Current time : 1658551472 Program is online. Time : 10:15:3

OPENING Program is online. Time : 10:18:3

OPENING PAIRING CONNECTED (SIGINT) Shutting down... PS D:\Whatsapp-Automation> node histogram_and_feature_detection_v21.js Client is ready! Time : 11:28:33

Program is online. Time : 11:29:24

CONNECTED Program is online. Time : 11:32:24

CONNECTED Program is online. Time : 11:35:24

[PurpShell]

Hmm hello everyone, I know this is kind of late, but why exactly is the page lagging/quitting?

I have run a whatsapp-web session with/without a restart for hours. For the projects where we had a periodic restart, it was using a cron package from npm and the client.destroy() function along with a new client.initialize()

I know that destroy causes an error (will fix that soon) but this seems absurd, do you have a lot of chats or some factor we haven't been informed of yet?

[angmon73]

Hello @PurpShell and thank you for your answer. In my case I have a lot of chats (abount 2-3 thousands in a day), but sometimes whatsapp-js stops after an hour from its last start. Unfortunately there are no logs or other to see what is happening. My client receives mostly text and videos, but none of them is very heavy (from 100 Kb to 4-5 MB for videos). Every chat is read only (I never send messages to customers): in every chat there are about 1-5 messages (the customers write messages to the radio they are listening). I had thought to introduce a system with an external controller and an heartbeat inside my script. In this way the controller could stop and restart the script when not receiving heartbeat. Unfortunately, restarting the script after this block, needs to read the QR code again, because the old current session is not more valid. So, I dont'have a solution and my script hangs 5-6 times every day!!!! I'm getting crazy...

[omarmyousef]

It's actually not lagging/quitting The page crashes with "Aw Snap!" message, whoever disables the Headless parameter of puppeteer can observe it The main reason as i know is High message rate and/or the increase of chats which causes memory lack and make the page crashes My own fix was to auto delete chats after the bot replies ( which may not be suitable for all projects ) but that helped to dramatically decrease crashes, went from crashing every hour to crash once a day, but that wasn't a total fix that's why i've created a ping function to detect client freezing using client.getState and restart if the result didn't get resolved in less than a minute (Which causes lag in replies in case of crashes)

[luiscuriel]

It's actually not lagging/quitting The page crashes with "Aw Snap!" message, whoever disables the Headless parameter of puppeteer can observe it The main reason as i know is High message rate and/or the increase of chats which causes memory lack and make the page crashes My own fix was to auto delete chats after the bot replies ( which may not be suitable for all projects ) but that helped to dramatically decrease crashes, went from crashing every hour to crash once a day, but that wasn't a total fix that's why i've created a ping function to detect client freezing using client.getState and restart if the result didn't get resolved in less than a minute (Which causes lag in replies in case of crashes)

This is exactly the behaviour I am getting. Whatsapps with a small number of chats can run for more than 1 week without a problem, but when we have 500 chats and lots of messaging it ends crashing and breaking the session files.

[omarmyousef]

This is exactly the behaviour I am getting. Whatsapps with a small number of chats can run for more than 1 week without a problem, but when we have 500 chats and lots of messaging it ends crashing and breaking the session files.

i've worked on two projects so far using whatsapp-web.js, one which has a little number of users and i finished working on it like 2 months ago, and it's still working perfectly right now without crashing once another one which is recieving a ton of new messages daily, and this one even if it's code works like the other one, it was crashing almost every hour That's why i had to make some implementations like deleting the chats as long as they aren't needed anymore, auto restart on failures, and making a queue for chat replying to not send many messages at the same time, and that made the software working better even with the auto restart being the major reason it's not the most stable package, but you can do some workarounds whatsapp unfortunately doesn't leave a better automation option in our case

[onurguven]

same here

[arbisyarifudin]

Same here.

[xanaxxx]

same here

[chagasjoao]

Same here

[elasti-co]

Same, it needs to restart every night.

[gitnasr]

So i have the same issue, i though it could be an Unhandled Exception so i used PM2 to restart the server whenever server crash. Surprisingly there's no exceptions at all. So I'm trying a new strategy that's restart server every 6 hours. That's will be good to narrow down the down time. Also I noticed that stuck happens when my app is idle (when no receiving messages or statuses). But I still not sure.

[gitnasr]

Also my simple logger says that it's stuck on OPENING

[dhruv9499]

It's actually not lagging/quitting The page crashes with "Aw Snap!" message, whoever disables the Headless parameter of puppeteer can observe it The main reason as i know is High message rate and/or the increase of chats which causes memory lack and make the page crashes My own fix was to auto delete chats after the bot replies ( which may not be suitable for all projects ) but that helped to dramatically decrease crashes, went from crashing every hour to crash once a day, but that wasn't a total fix that's why i've created a ping function to detect client freezing using client.getState and restart if the result didn't get resolved in less than a minute (Which causes lag in replies in case of crashes)

Can you share your solution, please?

[samuelfaj]

Same here.

As a workaround from time to time i will do a function (like see someone's status) and if it works, the client is Online.

[tanght1994]

same here

[kakoma]

Here's what I use for this - I put my own number in place of the xxxxxxxxxxxxx and that's it. This runs every 20 minutes and writes to the console whether all is well.

/**
 * Check if the WhatsApp client is still online
 * 
 */
async function isClientOnline(whatsAppClient) {
  try {
    const contactId = 'xxxxxxxxxxxxx@c.us';
    const contact = await whatsAppClient.getContactById(contactId);

    if (contact.isMe && contact.isUser) {
      console.log("Everything is fine. Everything's OK...");
    }
  } catch (error) {
    console.error("Error:", error);
  }
}

// Export a function to start the polling interval.
export function startPolling(client) {    
    const intervalInMilliseconds = 20 * 60 * 1000;// 20 minutes i.e. 20 minutes * 60 seconds * 1000 milliseconds
    setInterval(() => {
        isClientOnline(client);
    }, intervalInMilliseconds);
}

[LenonCalsavara]

I believe I discovered the problem, puppeteer saves by default in the /tmp the profile folder, when this folder fills up, it can no longer edit or open new connections, my folder is only 3.6Gb, so I put the folder to use /dev/shm which on my machine has a lot more. Example code:

puppeteer: { executablePath: '/usr/bin/chromium-browser', args: ['--no-sandbox', '--disable-setuid-sandbox'], ignoreDefaultArgs: ['--disable-dev-shm-usage'], ignoreHTTPSErrors: true }

There are files that continue to be stored in the /tmp folder, but dividing them between the 2 folders makes it take much longer for the service to crash. I also added a reboot on the server to clean the temporary folder. It's not the definitive solution, but for me, it solved the problem.