I'm getting the following error when an image is sent to the API user:
ERR! listen Error: unrecognized attach_file `{"blob_attachment":{"__typename":"MessageImage","attribution_app":null,"attribution_metadata":null,"filename":"image-1962166334031351","preview":{"uri":"<URL to the image>","height":280,"width":497},"large_preview":{"uri":"<URL to the image","height":480,"width":853},"thumbnail":{"uri":"<URL to the image>"},"legacy_attachment_id":"1962166334031351","original_dimensions":{"x":1920,"y":1080},"original_extension":"png","render_as_sticker":false}}`
ERR! listen at _formatAttachment (<PATH>node_modules/facebook-chat-api/utils.js:354:13)
ERR! listen at attachments.map.v <PATH>node_modules/facebook-chat-api/utils.js:376:55)
ERR! listen at Array.map (<anonymous>)
ERR! listen at Object.formatDeltaMessage (/home/sarithis/nodejs/own/chat666/node_modules/facebook-chat-api/utils.js:376:46)
ERR! listen at resolveAttachmentUrl (<PATH>node_modules/facebook-chat-api/src/listen.js:159:40)
ERR! listen at resolveAttachmentUrl (<PATH>node_modules/facebook-chat-api/src/listen.js:168:30)
ERR! listen at parsePackets (<PATH>node_modules/facebook-chat-api/src/listen.js:171:19)
ERR! listen at Array.forEach (<anonymous>)
ERR! listen at <PATH>node_modules/facebook-chat-api/src/listen.js:109:12
ERR! listen at tryCatcher (<PATH>node_modules/bluebird/js/main/util.js:26:23)
ERR! listen at Promise._settlePromiseFromHandler (<PATH>node_modules/bluebird/js/main/promise.js:510:31)
ERR! listen at Promise._settlePromiseAt (<PATH>node_modules/bluebird/js/main/promise.js:584:18)
ERR! listen at Promise._settlePromises (<PATH>node_modules/bluebird/js/main/promise.js:700:14)
ERR! listen at Async._drainQueue (<PATH>node_modules/bluebird/js/main/async.js:123:16)
ERR! listen at Async._drainQueues (<PATH>node_modules/bluebird/js/main/async.js:133:10)
ERR! listen at Immediate.Async.drainQueues (<PATH>node_modules/bluebird/js/main/async.js:15:14)
It's fixable by adding the following case statement in the _formatAttachment function in utils.js:
case undefined:
return {
type: "error",
// Save error attachments because we're unsure of their format,
// and whether there are cases they contain something useful for debugging.
attachment1: attachment1,
attachment2: attachment2
};
The attachment1 object doesn't contain an attach_type property, that's why it's undefined.
Are these attachments actually errors? Or have they just changed the format of the attachment object in such a way that it breaks our formatter?
If they're valid attachments, I'd imagine we should try not to return an error, otherwise this seems like a good change.
Looking at the attachment structure in the error message, it looks like a new format we need to handle, where now the type is stored in attachment1.blob_attachment.__typename...
{"blob_attachment":
{"__typename":"MessageImage",
"attribution_app":null,
"attribution_metadata":null,
"filename":"image-1962166334031351",
"preview":{"uri":"<URL to the image>", "height":280, "width":497},
"large_preview":{"uri":"<URL to the image","height":480,"width":853},
"thumbnail":{"uri":"<URL-to-the-image>"},
"legacy_attachment_id":"1962166334031351",
"original_dimensions":{"x":1920,"y":1080},
"original_extension":"png",
"render_as_sticker":false}
}
For now, we can probably handle the undefined case by checking the type in the new location and returning a photo attachment if the type is MessageImage.
var blob = attachment1.blob_attachment;
switch (blob.__typename){
case "MessageImage":
{
type: "photo",
ID: blob.legacy_attachment_id,
filename: blob.fileName,
thumbnailUrl: blob.thumbnail.uri,
previewUrl: blob.preview.uri,
previewWidth: blob.preview.width,
previewHeight: blob.preview.height,
largePreviewUrl: blob.large_preview.uri,
largePreviewWidth: blob.large_preview.width,
largePreviewHeight: blob.large_preview.height,
url: blob.large_preview.uri,
width: original_dimensions.x,
height: original_dimensions.y,
}
default:
throw new Error("unrecognized attach_file `" + JSON.stringify(attachment1) + "`");
}
@Sarithis can you try something like the above out and let us know if that helps?
I will have a PR on this shortly.
Sorry for not responding for a while. @mitchcapper's commit worked - image attachments are now properly interpreted
Thanks for reporting this issue and testing the PR, @Sarithis!
Most helpful comment
I will have a PR on this shortly.