Error: Invalid attachment id (509)

[arrjay]

one of my group chats likes to include...notably, gif keyboard inline with their group chat. this causes the entire mqtt session to disconnect/reconnect with the following messages in &bitlbee:

facebook - Error: Invalid attachment id (509)
facebook - Signing off.
facebook - Reconnecting in 5 seconds..
facebook - Logging in: Fetching contacts

and basically it's like starting facebook back up again.

I'm running the v1.0.0 tagged code against the bitlbee 3.4.2 branch here: https://github.com/bitlbee/bitlbee/tree/release-3.4.2

let me know if there's anything I can do to help debug this

[dequis]

Can't reproduce.

Does it happen with group chats only, or private chats too?

[arrjay]

as far as I've seen this is just in group chats

On Sat, Mar 12, 2016 at 9:38 PM, dx [email protected] wrote:

Can't reproduce.

Does it happen with group chats only, or private chats too?

—
Reply to this email directly or view it on GitHub
#73 (comment)
.

"Always love, hate will get you every time" - Nada Surf

[arrjay]

Actually, I just had a friend crash my instance via private message, Trying to get a test case out of her and have her try it against an instance with debugging on.

[arrjay]

If you have any recommendations beyond BITLBEE_DEBUG_FACEBOOK=1 in the env let me know

[jgeboski]

I hit this issue the other night, but did not capture the log. And I was just unable to recreate the issue. Does this happen reliably for you?

[arrjay]

It does, but I think I need to recreate my entire stack - the simple test
has been happily idling away, so I'm now wondering if it's an interaction
between textual and bitlbee. (Or rather, anything more complex than stock
irssi...)

rj

On Sun, Mar 20, 2016 at 1:44 PM, James Geboski [email protected]
wrote:

I hit this issue the other night, but did not capture the log. And I was
just unable to recreate the issue. Does this happen reliably for you?

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#73 (comment)

"Always love, hate will get you every time" - Nada Surf

[dequis]

Got this one

{
    "deltas": [
        {
            "deltaNewMessage": {
                "messageMetadata": {
                    "threadKey": {
                        "otherUserFbId": "..."
                    },
                    "messageId": "...",
                    "offlineThreadingId": "...",
                    "actorFbId": "...",
                    "timestamp": 1461827321444,
                    "tags": [
                        "source:chat:web"
                    ]
                },
                "attachments": [
                    {
                        "id": "10208007008265775",
                        "mimeType": "application/pdf",
                        "filename": "009de6b75d866744506fa85e216f84b7_labels.pdf",
                        "fbid": 10208007008265775,
                        "fileSize": 22190
                    }
                ]
            }
        }
    ],
    "firstDeltaSeqId": 19172,
    "lastIssuedSeqId": 19172
}

[INFO] facebook: POST Request (0x61d0001a34e0):
https://api.facebook.com/method/messaging.getAttachment
[INFO] facebook:   Content-Type: application/x-www-form-urlencoded
[INFO] facebook:   Connection: Close
[INFO] facebook:   Accept: */*
[INFO] facebook:   Content-Length: 267
[INFO] facebook:   Host: api.facebook.com
[INFO] facebook:   Authorization: OAuth ...
[INFO] facebook:
[INFO] facebook:   fb_api_req_friendly_name=getAttachment&aid=10208007008265775&
locale=en_US&format=json&device_id=...&sig=...&api_key=...&method=messaging.getA
ttachment&mid=...

May be worth noting that 10208007008265775 is just long enough to not fit in a float (converting to float and back to int results in 10208007008265776, that's +1), but that's probably not the issue here.

[dequis]

It's using FQL

{"url":"SELECT src FROM message_previewable_attachment_src
WHERE message_id='m_mid.1461...:fbd0...' and  attachment_id='1020...'"}

[dequis]

This seems to be random, some attachments of the same type (not just pdf as above, also images) sometimes also fail to be fetched. The float thing is a red herring, ignore that.

We seem to make that getAttachment call for every image and attachment, but latest orca doesn't need them for images (the full urls are included in the thrift payload, i guess).

Also it only does that FQL query when attempting to download attachments, not when first displaying them, and never for normal images.

This might mean I'll have to update the protocol to use the new mqtt topics, but in the meantime I could just prevent the reconnection and show an error message to the conversation instead.

[dequis]

I can't reproduce it anymore. Tried sending myself 100 tiny images, didn't happen a single time.

I'd appreciate if anyone could mention if it still happens, otherwise I'll just close this in a few weeks.

edit: Nevermind, saw one of those again.

[dequis]

This is handled by e094e5a currently in the development branch

[vortex1024]

I am still getting this. It happens intermittently when receiving voice messages. I guess I should make my own server to help debugging it, as I currently use someone else's and I can't enable debugging on it.

[dequis]

Nah, don't worry it's known and not fixed, it just won't disconnect you anymore.

[ikeblaster]

@dequis Google brough me here. I think we are dealing with the same problem (but it happens [also] for images).

Observation: when I try the same call a few minutes later, it returns correct data. Maybe a simple 10-100ms delay or few repeats in case of 509 would solve this.

Didn't try it yet, so can't say what delay is necessary and whether the simpler approach is "good enough".

[emmaccode]

one of my group chats likes to include...notably, gif keyboard inline with their group chat. this causes the entire mqtt session to disconnect/reconnect with the following messages in &bitlbee:

facebook - Error: Invalid attachment id (509)
facebook - Signing off.
facebook - Reconnecting in 5 seconds..
facebook - Logging in: Fetching contacts

and basically it's like starting facebook back up again.

I'm running the v1.0.0 tagged code against the bitlbee 3.4.2 branch here: https://github.com/bitlbee/bitlbee/tree/release-3.4.2

let me know if there's anything I can do to help debug this

Hi, 5 years later this is happening to me with messages between me and 1 other: my girlfriend , really weird... It happens when I try to send my location

[lderougemont]

Hello, for anyone looking to manage this error (for a bot transcribing audios for example), I created a fork where I corrected the 509 problem with attachments ids: https://github.com/lderougemont/bitlbee-facebook .

To reexplain the problem: facebook sends the attachment id before adding the file to its database, and asking for the link too fast finishes on this 509 error.

Two solutions (on two branches):

• solution-1: wait 1s before asking the link --> good solution, just that if we have another 509, the link/file is definitively lost for bitlbee
• solution-2: when detecting 509, reask after 1s (may be reduced to 0.5s ?) --> still ~1s lost, always works even if multiple 509 encountered (, in the code was a bit more difficult to manage due to the re-creation of a message for user id and thread id)

The master branch is set on solution-2 for the moment (and it works fine for me).

Note: may need some improvements (sol°2 may encounter infinite loop ?, change sleep duration ?, do not transmit 509 errors to the final user/bitlbee ?, I didn't tested the changes I made for g_memdup/g_memdup2 automatic check (I only have g_memdup2 for now), ...).

To install, just follow the manual install guide in the README (./autogen.sh && sudo make install).

Also, I don't do a pull request as I don't know which solution to keep (and if anyone is mainting this repo).