search

rHomelab / LabBot-Cogs

Cogs for the Red-based Homelab Discord server bot.
GNU General Public License v3.0
36 stars 14 forks source link

[FEAT] reactrole: check reactions on startup and process missed events #50

Open the1337g33k opened 4 years ago

the1337g33k commented 4 years ago

When the bot is offline people still react to the role post expecting their actions to be carried out. On startup the bot doesn't check the post and compare the current reactions against a user's roles to ensure everything is properly synchronized. Users may be unaware the bot is offline and become confused when it doesn't ever carry out their directives.

Only one thing I am aware needs to be considered when making this. Need to figure out if member cache is ready by the time the on_ready event is fired. We will want to make sure the member cache is fully built before running this process as we don't want to increase startup time or put the bot queue minutes behind right out of the gate after startup is complete.

issy commented 4 years ago

on_ready is triggered after the cache has filled, so this should be easy peasy to implement

the1337g33k commented 4 years ago

Yeah actually I was thinking of a second thing too just now. We want to consider a backoff in case discord, whilst known for it's rock solid stability just happens to get all flappy and cause the bot to fire on_ready multiple times in quick succession. We'd want to keep a record of the last time the process ran, check if a task is already scheduled to run and if not already scheduled, setup a task to run no less then an hour after the last time it ran.

issy commented 4 years ago

I believe (citation needed) that when Discord reconnects it fires on_resumed() rather than on_ready(), so it's definitely possible to log that data. However, I don't really see a need to not run the task. Worst case scenario it'll just error out quietly while Discord reconnects and then retry on connection

the1337g33k commented 4 years ago

I'll need to further research it. I know on_ready() firing multiple times was a problem in the v2 days. I have scars from tasks stepping on themselves repeatedly and causing inconsistency.

issy commented 4 years ago

As this cog doesn't utilise tasks that shouldn't be an issue. Though, in that instance it is generally best practice to have a on_disconnect() event that will cancel any running tasks