getThreadHistory: Filter out messages containing error attachments

[ivkos]

Fixes #357

[Schmavery]

Thanks for taking a look at this issue. I'm not totally sure how this solves any problems, were you able to replicate the problem in #357? I had thought the exception was being thrown from formatMessage.

In an ideal world would it be nicer if we could just format these errors like we do in listen?

[ivkos]

Yes, I do get the same messages with error attachments. The exception is thrown from _formatAttachment because it doesn't handle attach_type=error. The PR fixes that by handling this type of attachment and formatting it, while saving the original attachment(s). As far as I've tested, the original attachment doesn't contain any useful information about the error, but I thought it might be a good idea to save them just in case this changes or behaves differently on other accounts. The PR also filters out messages that contain error attachments, so they don't get returned in the result of getThreadHistory. If you want me, I can leave getThreadHistory as it is, so that it returns everything including messages with error attachments.

[Schmavery]

Oh I see now. Thanks for clarifying!
@bsansouci what do you think, are we good to merge?

[AlexGustafsson]

Are there a way of suppressing the warnings thrown?

[ivkos]

@AlexGustafsson Yeah, you can set the log level to one higher than "warn", i.e. "error" or "silent".

api.setOptions({ logLevel: "error" });

See api.setOptions for more info.

@Schmavery @bsansouci Do you think the "warn" level is appropriate for these messages? Should we use something lower, e.g. "info"?

[Schmavery]

Warn seems fine to me.
ping @bsansouci merge?

[bsansouci]

Do errors really not have a specific format? Did you encounter those in the wild? If you would you mind sharing the shape of the object.

[ivkos]

@bsansouci I encounter a few of them in a group chat with ~40k messages. So far, I've only come across error attachments that seem to be empty:

attachment1: { attach_type: 'error' }
attachment2: { id: '', image_data: {} }

However, I'm not sure if there are cases they contain useful information.

[bsansouci]

@ivkos Hey, thanks for the PR.
Am I understanding correctly that you're removing messages from the return of getThreadHistory if they had an attachment that has an error? That doesn't seem like a good behavior, as it seems like there would be no way for the user of this library to retrieve those specific message. I don't think we should filter the messages in this case.

Supporting the error type seems like a good thing though!

[Schmavery]

Thanks!