Buffer is full, dropping message in

[nefingar]

At the moment I'm not able to receive any messages with the bridge but sending one isn't a problem at all.

The error message i found inside the log file was:
[Jun 19, 2019 23:25:15] [User/***************/WARN] Buffer is full, dropping message in **************@s.whatsapp.net

I tried reconnecting, creating a new web whatsapp session and also restarting the whole bridge but I'm still getting the same error message.

[nefingar]

After a day or so, the bridge started to work normally again and the warning wasn't posted again in my log files. I think an automated restart of the bridge has fixed my issue, but I'm not completely sure, since restarting it manually hasn't made any difference.

[erdnaxeli]

I had the same issue, but rebooting the bridge was enough. I'm wondering what is the cause here. The bridge being unable to talk to the HS?

[vmario89]

hi. have the same problem with "buffer is full" after 1~2 days as it seems. restarts works

[nefingar]

I can confirm that. I encountered the error once more and by killing the process and starting it again the bridge starts syncing all chats again.

[olmari]

Can confirm too, it seems that when this condition occurs, I get buffer full warning somewhat every time I should get incoming message. At the logs I see connection timeouts etc similars happening at timestamps after buffer full thing is going on, but nothing helps but restart of bridge-service.

[thomersch]

Based on a quick look it seems that there are some systematic problems in the code structure. E.g. user.putMessage will throw the mentioned "Buffer is full" when getting back pressure from handleMessageLoop, which unnecessarily uses a mutex in order to write on a chan, which should never be necessary in Go. After all channels are the method which should substitute locking.

I would be happy to help with any effort to rewrite the code to use less mutexes.

[tulir]

The mutex isn't for locking the write on a chan, it's locking the processing of incoming messages. That locking is needed so that incoming messages wouldn't be handled while the bridge is backfilling after connecting, since handling those newer messages first would prevent backfilling.

[tulir]

This shouldn't be a problem for most users anymore. Some people with very big accounts might need to adjust the buffer config, but the defaults should be fine for most users.

I also switched the handleMessageLoop to use a channel and WaitGroup instead of a mutex for the channel, which should look less weird and might even be more performant.