Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix for the BigBrother consume_messages bug #348

Merged
merged 1 commit into from Apr 10, 2019

Conversation

Projects
None yet
3 participants
@SebastiaanZ
Copy link
Member

commented Apr 9, 2019

This PR is meant to close #347 and fix the issue that the watch channels would stop working after the consume_messages Task failed with an exception. I've made two changes:

  1. Catch the Forbidden or NotFound exceptions that may occur when trying to save an attachment from a message that was deleted. As I did not want to lose the information that the message originally contained an attachment, the bot will notify us of the missing attachment with the following embed:

Error message to watch channel

  1. Check if the consume_messages Task was done before resetting the self.consuming flag to False, as this should never happen. It will log the full traceback and restart the task to ensure that BigBrother doesn't fail completely.

    There's a limitation to this: In the current design, the message queue gets copied to a temporary, local-scope queue at the start of consumption. If the Task fails, this temporary queue will be lost and the original message queue will have been cleared. This will result in some messages not being posted to the watch channel.

    However, I did not want to restructure this, as it would constitute a major change in the way BigBrother works. I also don't think those few messages that get lost are critical. For those two reasons, I'd rather fix this is #317 than here.

Finally, I could have caught the exception in the send_attachments function in the messages.py cog, but I think it's better to handle it where it occurs, so the handling can be customized to that part of the code. In this case, I wanted to send that notification embed to the watch channel, but I can imagine going for a different approach if this happens in another cog.

@MarkKoz

MarkKoz approved these changes Apr 9, 2019

Copy link
Contributor

left a comment

Looking back at BB as a whole, there's definitely some design choices to reconsider. I think you've managed to elegantly patch this though. For now, we'll live BB as is. Looking forward to #317.

@GhostofGoes GhostofGoes merged commit b5235cb into master Apr 10, 2019

@GhostofGoes GhostofGoes deleted the bb-uncaught-exception-fix branch Apr 10, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.