dequis / purple-facebook

Facebook protocol plugin for libpurple (moved from jgeboski/purple-facebook)
GNU General Public License v2.0
955 stars 88 forks source link

Renamed chats causes prpl to disconnect #244

Closed acli closed 7 years ago

acli commented 8 years ago

The prpl (version 66ee77378d82 in git) appears to be not handling renamed chats correctly. If the user is in a group chat that is renamed, the prpl crashes soon after login with a “Failed to parse thread information” error and the facebook account is disconnected (cf. #214 ).

If the “|| !haself” check in api.c (what causes fb_api_thread_parse to return the FALSE which is interpreted as “Failed to parse thread information”) is commented out, the prpl doesn’t crash but the renamed chats are not loaded.

This suggests that “haself” is probably not the correct condition to check for and something else is missing which is causing named group chats to be not recognized as chats the user is participating in.

104 suggests that this might be a regression.

dequis commented 8 years ago

Backtrace? Debug log?

acli commented 8 years ago

Reenabling the haself check hasn’t caused the crash to reappear, so somehow pidgin seems to be remembering which chats have been ignored. I’ll try to set up a new renamed chat and when it crashes I’ll email you the logs.

acli commented 8 years ago

Actually I do have an old debug log from before I patched the prpl, but I don’t have a gdb trace. I’ll have a new set when a new chat is set up and causes a crash.

dequis commented 8 years ago

The debug log doesn't seem to have anything like a crash, it looks like it exits normally unloading everything properly.

I can't reproduce the bug by renaming a chat.

dequis commented 8 years ago

What distro? You might already have something that catches crashes, for example coredumpctl in systemd based distros, apport in earlier ubuntu, abrt in fedora.

acli commented 8 years ago

Hmm. Maybe it didn’t crash the prpl then. Let me rename the bug. This is Ubuntu 15.10.

dequis commented 8 years ago

Okay, JnNy from #bitlbee provided a proper debug log for an issue that seems to be equivalent to this.

It's not "renamed" as in "changed the topic", it's "renamed" as in "kicked out of the old one and created a new one", so now i can reproduce this.

The result is that the thread information is queried when attempting to join, and the reply doesn't have self in all_participants, as the first post of this ticket suggests. This should be a non-fatal join error, not a connection error.

{
  "[...]": {
    "all_participant_ids": null,
    "all_participants": ["..."],
    "can_viewer_reply": false,
    "cannot_reply_reason": "VIEWER_NOT_SUBSCRIBED",
    "customization_info": null,
    "delivery_receipts": ["..."],
    "ephemeral_ttl_mode": 0,
    "folder": "INBOX",
    "former_participant_ids": null,
    "former_participants": ["..."],
    "has_viewer_archived": false,
    "id": "[...]",
    "image": {
      "uri": "[...]"
    },
    "is_group_thread": true,
    "is_viewer_subscribed": false,
    "last_message": {
      "nodes": [
        {
          "__type__": {
            "name": "ParticipantLeftMessage"
          },
          "message_sender": {
            "email": "[...]",
            "messaging_actor": {
              "__type__": {
                "name": "User"
              },
              "id": "[...]",
              "name": "[...]"
            }
          },
          "snippet": "[...] removed you from the group."
        }
      ]
    },
    "messages": null,
    "mute_until": -1,
    "name": "[...]",
    "read_receipts": ["..."],
    "thread_key": {
      "other_user_id": null,
      "thread_fbid": "[...]"
    },
    "unread_count": 0,
    "updated_time_precise": "[...]"
  }
}

(note to self: full log in dir=rupiah)

dequis commented 7 years ago

This is fixed in 0.9.5

https://github.com/dequis/purple-facebook/releases/tag/v0.9.5-9ff9acf9fa14