purple-facebook
purple-facebook copied to clipboard
dequis
sending duplicate messages
When I send a message, it seems to actually get sent multiple times. The person on the other end gets duplicate copies. I can even see the duplicates on another device I am logged in with.
I'm using 0.9.5-9ff9acf9fa14.
I've seen this happen when people share access tokens across multiple instances of this plugin. If you do that, force one of them to log out by deleting the account or revoking the session from the security section of facebook
I don't believe I have multiple instances of the plugin. There is only the one machine that I use the purple facebook plugin.
I am experiencing the same/very similar issue on the sailfish X implementation. I receive messages from myself and duplicates of all messages that are not marked as read. If I access facebook messenger to mark the messages as read they stop appearing. Until then it keeps spamming me with the messages I have received and sent.
@dequis I think they're talking about this: https://openrepos.net/content/nodevel/facebook-messenger-account
@dequis Thats just a an frontend to make an account. It still uses telepathy-haze. So its not a special case
Oh, telepathy-haze. That is a different issue from what OP posted. Receiving incoming messages from others multiple times in clients that aren't pidgin is #280
Sending your own messages multiple times is what this ticket is about. It's something else.
Ok, maybe I mixed that up. I thought the issue lies in telepathy-haze as both messages types get resend when reconnecting (mine and other I got). All messages I send are seen as I send those to me.
I get this very often when I'm on planes or anywhere with high latency or high packet loss...
I'm seeing many messages I send being duplicated and constantly reappearing. It is possible other messages from other people are also duplicated. I am using pidgin-2.13.0-1.mga7 on mageia 7.
I still have this issue, where sometimes my messages are sent multiple (sometimes even 20) times. I have seen this happen only in group chats so far, and only when I send URL links. I do use pidgin plugin on multiple devices, but every device has its own app password, none is shared. Any ideas? Debug log sent by email.
@jurajQ: your debug log doesn't have any sent messages, just a normal connection and disconnection with no activity inbetween, so i can't really do much with this.
Aha! Got another one from @jurajQ. Now this is interesting. Thanks!
Trimmed down debug log:
(10:41:47) facebook: Writing message (topic: /send_message2)
(10:41:48) facebook: Reading 4 (flags: 0x2)
(10:41:48) facebook: Reading 3 (flags: 0x0)
(10:41:48) facebook: Reading message (topic: /t_p)
(10:41:48) facebook: Presence: [...] (1)
(10:41:48) blist: Updating buddy status for [...] (Facebook)
(10:41:49) facebook: Attempting to reconnect the MQTT stream...
Then it reconnects and tries to resend the message because it didn't get acked by the server. Repeat in a loop possibly forever, until ctrl-c.
The message sent is a direct link to a knowyourmeme cdn image. Seems like a poor choice to flag as likely-spam if that's what's happening. But if it was spam filtering why is it killing the (easily reconnectable) mqtt stream without dropping the message?
Does this happen with all the links, and all groupchats?
Hi, thanks for the swift reaction. Although I do not know if it's a spam issue, it does happen only for links and only for groupchats. It happens for many types of links, e.g. for youtube as well as other "trusted" sites.
I cannot say whether it happens for all groupchats, as I am sending links only in one. However, I cannot say that it happens for all links that I send. Many times, they are sent normally. I will try to find a pattern in where it happens (in work, at home etc) and for what types of links, but it's hard to experiment when one is bothering people in groupchats with 20 messages in a row :P
Hi, I get the same here, and sometimes I receive a couple of messages many times (when I log in to pigdgin in the morning for exemple and I got messages in the night) The messages are received many times by ordered groups.
maybe a quite dirty fix could be in both receiving and emiting message to manage a small cache of latest message for let say 1-5seconds , an on a new message compare it to cache to know if it has to be resent (a full message cache or a hash sum of the message should do the trick)
This should not be overkill for this kind of program because of expected processed data amount. But I understand that my solution is not the proper way to solve the issue and that it would be preferable to find the root cause more than occulting the issue.
